Tales From A Lazy Fat DBA

For most of its life, GoldenGate has done one job and done it well, I really like the product 🙂 … moves rows from A to B, fast, without dropping a single change. Capture, pump, apply. That was the whole deal. If you wanted to do something smart with that data on the way (turn it into vectors, run it through a model), that was somebody else’s job further down the line. Usually it meant a separate app, a queue, and a pile of custom code nobody wanted to own on a weekend or friday evening 😀

That has changed in GoldenGate 26ai. Starting with Release Update 23.26.1.0.0, there is a real AI service built into the deployment, and the first thing it lets you do is make vector embeddings right inside the Replicat process. No outside app. No separate batch job that runs at 2 AM and is always behind. You map a text column to an embedding model, and GoldenGate writes the vector into your target as part of the same apply that writes the rest of the row.

I’ve seen enough people bolt embedding pipelines onto the side of a replication stream to know how much work this removes. So let me walk through what the feature actually is, how it’s wired, and what a working Replicat mapping looks like.

Everyone is chasing semantic search and RAG right now. All of it runs on vector embeddings, which are just numbers that stand in for the meaning of some text instead of its exact spelling. The hard part was always when and where you make those vectors. The old way looked like this … you’d test the embedding model from the OCI console or an API client, confirm it works, then build a proper backend app that reads rows, calls the model, and writes the vectors back. It works, but now you own a whole app … its scaling, its failures, and the constant lag between a row changing and its embedding catching up. Every insert on the source becomes a future embedding job somewhere else.

GoldenGate 26ai’s answer is simple: stop treating embedding as a downstream problem. GoldenGate already touches every changed row in real time, so it just does the embedding right there … Yeah!!! \,,/

There are really only two new things to learn — The first is the AI Service itself, a new microservice in your 26ai deployment. If you list processes on the box, you’ll see it running:

[oracle@fatdba1 bin]$ ps -ef | grep AIService
oracle   60905 60721  0 20:50 ?  00:00:00 /u01/app/oracle/product/ogg26ai/bin/AIService

Its job is to hold the connections out to your embedding models (local or remote) and hand back vectors when Replicat asks. Right now it does embeddings. Oracle has said this same service will later carry LLM features too (things like finding names or PII in the data, natural-language admin, and so on). For now, just think of it as GoldenGate’s own middleman to the model providers.

The second piece is a new Replicat function, @AISERVICE. You call it inside a COLMAP to say: take this text column, run it through this model, store the vector in this target column … The providers supported at launch are OCI Generative AI, OpenAI, Google Gemini, and Voyage AI, plus custom setups over ONNX or OpenAI-style APIs. The bring-your-own-model part is real, which matters if you run a local model because customer text isn’t allowed to leave your network.

Almost all the setup lives in Service Manager, and the order matters. There are four things to get right before a single embedding gets made.

1. Proxy first. Your GoldenGate box is almost certainly inside a corporate network with no direct route to the internet, and the model providers live outside that wall. So you point GoldenGate at your outbound proxy with HTTP_PROXY and NO_PROXY. Nothing fancy, but if you skip it, every call to OpenAI or OCI just times out, and you’ll spend an afternoon blaming certificates when it was routing all along.

2. Certificates second. Because these are secure (TLS) calls out to the providers, GoldenGate needs the CA certificate for whichever one you use. The clean way to grab it is straight from the endpoint with OpenSSL ..

# For OpenAI
openssl s_client -showcerts -connect api.openai.com:443

# For OCI Generative AI (Chicago region shown; use your own region's endpoint)
openssl s_client -showcerts -connect inference.generativeai.us-chicago-1.oci.oraclecloud.com:443

Pull the certs out of that output and load them into the Service Manager certificate store. This is the step people most often trip on, usually because they forget the AI endpoint’s CA chain is not the same as the certs they already trust for their database connections.

3. Provider and model third. In Service Manager, under the AI section, you set up the provider and the model. For a simple provider like OpenAI you just give the Base URL and an API key. For OCI Generative AI there’s more, because OCI login is OCI login: the Base URL, the API key, and the cloud identity bits (tenancy OCID, compartment OCID, user OCID, and the key fingerprint). Then in the Model section you name the actual embedding model, for example text-embedding-3-small on OpenAI, or cohere.embed-english-v3.0 on OCI. That model name is what you’ll type into the Replicat later.

4. Check it’s live fourth. Before you touch a Replicat, confirm two things. One, the AI Service shows as enabled and running under the Services section of Service Manager. Two, the model is visible from your user deployment, not just the Service Manager deployment. Those are two different deployments, and the model has to show up in the one your Replicat actually runs in. This catches people out constantly. Check it now and save yourself the head-scratching later.

Here’s where it pays off, and it’s almost too easy. You just add the embedding to the COLMAP of your normal MAP statement… Say you have a source table PARKS with a PARK_ID and a DESCRIPTION column holding text. Your target table PARKS_AI has the same columns plus a new one, DESC_VECTOR, defined as a VECTOR. You want everything to copy across as normal, and DESC_VECTOR to hold the embedding of DESCRIPTION :

MAP source.PARKS, TARGET target.PARKS_AI,
COLMAP (USEDEFAULTS,
    DESC_VECTOR = @AISERVICE(embed, 'cohere.embed-english-v3.0', DESCRIPTION)
);

That’s the whole trick. USEDEFAULTS copies PARK_ID and DESCRIPTION across as-is. The one extra line says: take DESCRIPTION, send it to the cohere.embed-english-v3.0 model through the AI Service, and store the vector it returns in DESC_VECTOR. As each change flows through Replicat, the embedding is made right there and saved with the rest of the row. Source and target stay in step, and there’s no separate job to fall behind, watch, or restart. The nice bit of flexibility: because the model is just an argument to the function, you can send the same source table to two targets using two different providers. One Replicat on OCI, another on OpenAI, same data:

-- Replicat 1: embed using OCI GenAI (Cohere model)
MAP source.DOCS, TARGET lakehouse.DOCS_OCI,
COLMAP (USEDEFAULTS,
    CONTENT_VEC = @AISERVICE(embed, 'cohere.embed-english-v3.0', CONTENT)
);

-- Replicat 2: embed the same text using OpenAI
MAP source.DOCS, TARGET lakehouse.DOCS_OPENAI,
COLMAP (USEDEFAULTS,
    CONTENT_VEC = @AISERVICE(embed, 'text-embedding-3-small', CONTENT)
);

Same text in, two different embedding models out. If you’ve ever had to compare one embedding model against another on live production data, you know that’s normally a small project. Here it’s two lines of parameter file.

These are the things that will actually cause issues, so I’m calling them out.

• The target vector column must already exist before you reference it. Oracle’s reference guide is clear on this: the embedding column has to be added to the target table first, then you can point @AISERVICE at it in the Replicat. If you write the mapping before the column exists, it won’t work. So the order is: add the VECTOR column to the target, then write the mapping.
• In 23.26.1, @AISERVICE takes one column only, not an expression. You cannot do something like first_name || ' ' || title inside the function. As of this release it expects a single input column, full stop. In real life you often want a richer text payload (name plus title plus department, say) to get a more useful vector, so plan for that. If you need combined text, build that combined value into a column upstream (or as a virtual/derived column) and point @AISERVICE at that single column instead.
• The target column has to actually be a VECTOR type. Don’t try to shove embeddings into a CLOB and hope. In practice this means a database that supports the vector datatype, with Oracle AI Database 26ai (or 23ai) with Vector Search being the obvious home. Define the column as VECTOR properly and you’re fine.

You’re making a network call out to the model for every row that hits the mapping. That’s real time and, on a paid API, real money per call. For a steady stream of OLTP changes that’s usually fine. But if you’re doing a huge first-time load of a hundred-million-row table, stop and think about volume, speed, and your provider’s rate limits before you turn it on. Embeddings made in real time are great. Embeddings made in real time across ten million rows during a Monday morning reload can surprise you, both on the clock and on the bill. …. And remember the two-deployment gotcha from setup, because it’s usually the first error you’ll hit: Service Manager holds the provider and certificate config, but the model has to be visible in the user deployment where your Replicat runs. When @AISERVICE complains about an unknown model, that mismatch is the first place to look.

Vector embeddings are the headline, but they’re clearly just the start. Oracle has set up the AI Service as the one microservice that all future AI features will run through. The roadmap they’ve published talks about spotting names and PII in the data as it moves, natural language admin of GoldenGate itself, and agent style APIs like MCP. Whether all of that lands on time is a separate question, but the direction is clear: GoldenGate is moving from a pure change-capture engine into something that also understands and enriches the data it carries.

For those of us who’ve spent years keeping replication lag under control and Extract processes healthy, that’s a genuinely different job description. The good news is that the first thing they shipped, inline embeddings, is small, well-scoped, and solves a real problem people have today. You can turn it on with a couple of lines in a COLMAP and delete a whole downstream pipeline in the process. That’s the rare kind of feature that makes your setup simpler instead of adding one more thing to babysit ….. If you’re already on 23ai, getting here is just the January bundle patch (23.26.x), not a migration, so there’s very little between you and trying it. Set up a provider, point a test Replicat at a text column, and watch vectors show up in the target as the rows land. It’s a good afternoon’s experiment, and it’ll change how you think about what GoldenGate is actually for.

Hope It Helped!
Prashant Dixit