Gluesync Couchbase DCP source agent: native CDC without Eventing

Gluesync 2.2.11.2 adds a source-only Couchbase DCP source agent. It reads Couchbase’s native Database Change Protocol stream for change data capture.

If you’ve ever wanted Couchbase CDC without standing up Eventing, this is that path. No Eventing service. No Eventing functions to deploy. Nothing written into the source bucket. Community Edition and Enterprise Edition are both in scope, Capella included.

One important nuance: this sits next to the Eventing source we already ship. It’s not a kill-and-replace. Two ways in. Pick the one that matches how your cluster is actually run.

Docs: Change data capture (DCP).

Why a native DCP path

Eventing-based CDC is still a solid Gluesync option when you want the bundled Eventing functions and you’re fine running the Eventing service on Enterprise Edition. Plenty of environments can’t, or simply don’t want to:

• run Eventing at all (footprint, sizing, who owns it)
• write helper or event documents into the source bucket
• stay on Community Edition and still get source CDC

DCP is Couchbase’s native change stream. The new agent opens that stream, captures changes, and leaves the bucket alone.

What shipped in 2.2.11.2

• A new Couchbase DCP source agent
• Role: source only (Control Plane picker: source, not target)
• CDC via native DCP
• No Eventing service, no Gluesync Eventing functions, no writes to the source bucket
• Works on Community Edition and Enterprise Edition

Shared Couchbase snapshot and discovery still come from the parent Couchbase module. This agent does not become a target. Target writes stay on the separate Couchbase target agent.

DCP vs Eventing: two source agents

	DCP source	Eventing source
Role	Source only	Source only
CDC mechanism	Native DCP stream	Eventing service + bundled functions
Eventing required	No	Yes
Writes to source bucket for CDC	No	Eventing path writes event docs (see Eventing docs)
Editions	CE and EE	Eventing path needs Enterprise Edition (see Eventing docs)
When to use	Prefer native stream / no Eventing / CE	Prefer existing Eventing-based deployments

Both stay in the catalog. Overview: Couchbase agent intro. Eventing path: Change data capture (Eventing).

Versions and stream modes

Stream shape depends on Use Scope and Collections:

• On: server-side scope/collection filter. Needs Couchbase 7.0+.
• Off: whole-bucket DCP stream. Couchbase 6.x is supported.

So don’t summarize this as “Couchbase 7.0+ only.” That’s true for scoped streams, not for whole-bucket mode.

And don’t copy Eventing-only settings (worker counts, script timeouts, language compatibility) onto this agent. They don’t apply.

Connection notes (boring on purpose)

In the Control Plane, pick the Couchbase DCP source agent as a source. The connection form looks like the shared Couchbase host fields. Management port defaults to 8091, or 18091 when TLS / Capella is on.

For Capella, use the cluster hostname (for example cb.XYZ.cloud.couchbase.com) and the TLS management port as documented.

Edition-specific roles and Data Service / DCP connectivity live in the DCP docs. Use credentials that can open a DCP stream on the source bucket, and follow the published prerequisites rather than improvising firewall or RBAC shortcuts.

Deletions and entity matching

When scopes and collections are off, the agent reads a whole-bucket stream:

• Live documents match entities via the document type field (snapshot matching uses the equivalent type filter).
• Deletion events have no document body. Matching relies on the document id / key pattern.
• A deletion is admitted only when its key is the entity metaId or can be decomposed with documentKeyResolution.
• A multi-entity setup that uses a plain metaId key is rejected at setup, because deletions can’t be assigned safely to an entity.

So don’t promise that every delete in the bucket always replicates in every entity layout. Design keys for unambiguous deletion matching, or use a layout the setup checks accept. Details: entity and deletion matching in the DCP docs.

Where it fits

Typical pattern: Couchbase DCP source into a Gluesync pipeline, then any supported target. Capella or self-managed Couchbase on the source side; warehouse, lake, RDBMS, or NoSQL on the other.

If Eventing-based Couchbase CDC already works for you, you don’t have to migrate. If you need native DCP, Community Edition, or a no-Eventing source path, this is the new option.

Next steps

1. Read Change data capture (DCP).
2. Skim Couchbase agent intro so DCP source, Eventing source, and the target agent stay distinct in your runbooks.
3. Deploy Gluesync 2.2.11.2+, pick the Couchbase DCP source agent, point it at your bucket (and Capella hostname if that’s your cluster).

Want to try it on your cluster? Request a free trial or book a demo. Questions on a concrete Hub build: I am around.