Canonical: https://molo17.com/solutions/replicate-to-couchbase/ Markdown mirror: https://molo17.com/solutions/replicate-to-couchbase/index.md Title: Replicate to Couchbase in real time with Gluesync | MOLO17 Description: Real-time replication to Couchbase from Oracle, SQL Server, PostgreSQL, and MongoDB, in paged SDK key-value writes, snapshot first, then CDC. Start a trial. [Solutions](/solutions/) Replicate to Couchbase SOLUTION · REPLICATE TO COUCHBASE # Real-time data replication to Couchbase from your operational databases **Committed changes from your systems of record land in Couchbase continuously, as paged key-value writes through the vendor SDKs, instead of waiting for the next scripted load.** Gluesync by MOLO17 captures changes from Oracle, SQL Server, PostgreSQL, IBM i, MongoDB, and other [heterogeneous sources](/integrations/?target=Couchbase#integration-finder) with a dedicated agent per database, then writes them to Couchbase Server through a target agent built on the Couchbase Java and Kotlin SDKs, a vendor-certified integration. Snapshots load each table into its own collection, CDC follows as changes happen, and Core Hub, the Gluesync control plane, runs every pipeline from one web UI and REST API. [Start a Gluesync trial](/get-gluesync/) [Talk to us](/contacts/) WHO THIS IS FOR ## Teams that serve Couchbase apps and mobile or edge read layers from systems of record - Couchbase administrators and analytics engineers who query documents with N1QL and need them to follow relational or document systems of record, without a loader for each table - Data platform leads who run Couchbase beside Oracle, SQL Server, and IBM i and want one Core Hub for every source, backed by [best-in-class enterprise support, rated 4.9/5 by customers](/support/#customer-ratings) - Architects designing a mobile, edge, or microservices read layer on Couchbase, who need the snapshot, the collection layout, and the write settings decided before go-live - Engineers replacing a Kafka Connect Couchbase sink or nightly sync scripts, who want [every source](/integrations/?target=Couchbase#integration-finder) delivered to Couchbase by one product, with snapshots and monitoring built in THE PROBLEM ## Couchbase documents loaded in batches are already stale Couchbase documents that mirror operational data are typically loaded by scheduled scripts: a job queries the source, converts rows to JSON, and writes documents on a timer. Apps then read the state at the last run, each run adds load to the production database, and every source ends up with its own script and failure mode. Teams looking for real-time Couchbase ingestion or a Couchbase CDC pipeline usually compare the Couchbase Kafka connector with Kafka Connect sinks, Debezium with a custom sink, Couchbase XDCR for cluster-to-cluster copies, or loaders they write with the Couchbase SDK. Gluesync addresses that with **per-agent CDC into Couchbase**. A source agent reads each database's native change mechanism, Core Hub routes the changes, and the Couchbase target agent writes them with key-value operations in real time. Oracle to Couchbase, SQL Server to Couchbase, or IBM i to Couchbase all share the same snapshot, pipeline model, and operations. HOW IT WORKS ## How Gluesync writes to Couchbase ### The write path: key-value operations through the Couchbase SDKs The Couchbase target agent uses the Couchbase Java SDK and Kotlin SDK, which are jointly validated with Couchbase engineering. The agent discovers cluster nodes automatically and supports high availability and load balancing across nodes. Writes go directly to the cluster through the SDK. Full-table, mapping, and query entities write inserts, updates, and deletes as key-value operations; data-modeling entities write inserts and updates as key-value operations and run deletes as N1QL queries. ### Optimized write pages Gluesync never handles Couchbase writes one document at a time. Incoming changes are grouped into write pages, and each page is sent to the cluster through the SDK's key-value API, which spreads the work across the data nodes that own each key. The page size is configurable. Client-side compression is configurable on the agent, and a document TTL can set an expiry for replicated documents. ### Collections: one per source table - **Created for you:** with collections on by default, the agent creates a collection for each source table when none with that name exists, and reuses a collection whose name matches the table. - **Default scope:** when the source has no schema, documents land in the `_default` scope. - **Sync Gateway:** Gluesync can run alongside Sync Gateway on the same data bucket. ### Snapshot first, then continuous CDC - **Seed:** the snapshot loads each table into Couchbase before CDC starts. - **Stream:** inserts, updates, and deletes are applied in real time after the snapshot. - **Resume:** an interrupted snapshot resumes from its last saved state when you start the entity again. - **Duplicate keys:** **Upsert** is the default and overwrites the document. **Skip** keeps the document already in Couchbase and raises a Notifications Hub warning that names the skipped keys. **Fail** stops the entity so the collision can be reviewed. ### What your Couchbase admin sets up The agent needs a user with read and write access to the target bucket, the cluster hostname or a node IP, and TLS when the cluster uses it. Capella clusters use the cluster hostname with a `.pem` certificate. The full steps are in the [Couchbase target setup guide ↗](https://docs.molo17.com/gluesync/latest/agents/couchbase-target.html). 1. Create a user with read and write access to the target bucket. 2. Open the cluster ports the agent needs, including the REST ports (8091 to 8096, or 18091 with TLS), as listed in the target setup guide. 3. In Core Hub, enter the hostname, the port (8091 by default, or 18091 for Capella and secured connections), the bucket name, and the user's credentials. 4. For TLS, enable it and upload the certificate. For Capella, use the cluster hostname and the `.pem` certificate. ### Architecture around Core Hub Core Hub orchestrates every source agent and the Couchbase agent through its web UI and REST APIs. A pipeline groups a source agent, the Couchbase agent, and the entities they replicate. Core Hub and the agents deploy with Docker, Docker Compose, or Kubernetes, on-premises or in any cloud. See [CDC streaming](/solutions/cdc-streaming/). [Explore the general CDC streaming architecture →](/solutions/cdc-streaming/) WRITE OPTIONS ## The Couchbase target agent: one agent, key-value writes Couchbase has one Gluesync target agent. Most entities write with key-value operations, and deletes for data-modeling entities run as N1QL queries. | Agent | Write technique | Versions | Best for | | --- | --- | --- | --- | | [Couchbase agent ↗](https://docs.molo17.com/gluesync/latest/agents/couchbase-intro.html) | Couchbase Java and Kotlin SDKs; paged key-value writes, N1QL for data-modeling deletes | Couchbase Server 7.0 and later, self-managed or in Capella DBaaS | Operational data that apps read from Couchbase as it changes: mobile, edge, and microservices read layers, and offloads from relational systems. Pair any Gluesync source agent with it under the same Core Hub. | SOURCES AND TOPOLOGIES ## Feed Couchbase from the systems of record you already run Any Gluesync source agent can feed Couchbase, each with its own native capture technique. Open the [integrations finder with Couchbase pre-selected](/integrations/?target=Couchbase#integration-finder) to see every source you can pair with it. Need to capture from Couchbase? See [Couchbase CDC](/solutions/couchbase-cdc/). One Core Hub runs several sources into the same cluster side by side, each pipeline with its own snapshot, monitoring, and duplicate-key policy. Gluesync keeps pace with your change volume at any scale, and write settings are configurable on the agent. [MOLO17 Professional Services](/solutions/professional-services/) can help plan buckets, collections, and the topology. - Oracle to Couchbase from the redo logs through LogMiner or XStream: see [Oracle CDC](/solutions/oracle-cdc/) and the [Oracle to Couchbase tutorial](/blog/gluesync-tutorial-series-keep-in-sync-oracle-database-with-couchbase/) - SQL Server to Couchbase through Change Data Capture or Change Tracking: see [SQL Server CDC](/solutions/sql-server-cdc/) - MongoDB to Couchbase from Change Streams: see [MongoDB CDC](/solutions/mongodb-cdc/) - IBM i (AS/400) to Couchbase from the native journal APIs: see [IBM i CDC](/solutions/ibm-i-cdc/) FAIR, HIGH-LEVEL COMPARISON ## Where Gluesync fits among Couchbase ingestion approaches | Approach | What buyers usually get | Where Gluesync fits | | --- | --- | --- | | Couchbase Kafka connector and Kafka Connect sinks | Kafka-based delivery into Couchbase through a connector; you run Kafka, Connect, offsets, and schemas | Changes go straight to Couchbase with no Kafka cluster in the path, and Kafka stays available as another target; read the [Debezium alternative](/solutions/debezium-alternative/) comparison | | Debezium with a custom sink | Open-source capture into Kafka topics, with a sink your team writes and operates to apply documents to Couchbase | Native capture per source agent and a Couchbase target agent built on the vendor SDKs, managed from one Core Hub | | Couchbase XDCR | Native replication between Couchbase clusters; it moves data from one Couchbase cluster to another rather than from relational systems | Gluesync brings Oracle, SQL Server, IBM i, and MongoDB data into Couchbase, and XDCR keeps Couchbase clusters in step with each other where you use it | | Couchbase Sync Gateway | Sync for mobile and web clients on top of Couchbase Server, with apps reading and writing through the gateway | Gluesync runs alongside Sync Gateway on the same data bucket and feeds that bucket from systems of record outside Couchbase | | Custom loaders written with the Couchbase SDK | Full control of document shape and key layout; your team owns retries, ordering, and the load each run puts on production | Continuous CDC from the source log, snapshot resume, and Core Hub monitoring, with no loader code to maintain; read [batch ETL vs real-time replication](/blog/batch-etl-vs-real-time-data-replication/) | RELATED CONTENT ## Couchbase replication tutorials, case studies, and deployment detail - [MongoDB to Couchbase: recorded webinar](/blog/webinar-on-real-time-data-replication-from-mongodb-to-couchbase/) - [MongoDB to Couchbase: a real-time tutorial](/blog/real-time-data-replication-from-mongodb-to-couchbase-tutorial/) - [Scopes and collections for Couchbase 7](/blog/gluesync-advanced-tutorial-getting-started-with-scopes-and-collections-for-couchbase-7/) - [IBM i data offloaded to Couchbase Mobile for a sales force](/blog/myo-ibmi-couchbase-mobile-sales-gluesync-case-study/) - [AI and RAG: continuously synchronized stores](/solutions/ai-rag/) - [Couchbase agent overview ↗](https://docs.molo17.com/gluesync/latest/agents/couchbase-intro.html) - [Couchbase target setup guide ↗](https://docs.molo17.com/gluesync/latest/agents/couchbase-target.html) - [Write strategies: optimized batches ↗](https://docs.molo17.com/gluesync/latest/core-hub/write-strategies.html) FAQ ## Couchbase replication questions What does replicating to Couchbase with Gluesync involve? A source agent captures committed changes from your database through its native change mechanism, Core Hub routes them, and the Couchbase target agent writes them as documents continuously after a snapshot loads each table. How does Gluesync write to Couchbase? The target agent uses the Couchbase Java and Kotlin SDKs with key-value operations, grouped into optimized write pages, and deletes for data-modeling entities run as N1QL queries. The integration is vendor-certified and was validated jointly with Couchbase engineering. Which Couchbase versions and deployments are supported? Couchbase Server 7.0 and later, self-managed or in Couchbase Capella DBaaS. How are source tables mapped to Couchbase collections? With collections on by default, Gluesync creates a collection for each source table when none with that name exists, and reuses a matching collection when one is already there. What happens when a document id already exists? Upsert is the default and overwrites the document. Skip keeps the existing document and raises a Core Hub warning that names the skipped keys, and Fail stops the entity so the collision can be reviewed. What does the Couchbase admin need to set up? A user with read and write access to the target bucket, the cluster hostname or a node IP, and TLS with a certificate when the cluster uses it. Capella clusters use the cluster hostname with a .pem certificate. Can Gluesync run alongside Couchbase Sync Gateway? Yes. Gluesync is designed to work with Sync Gateway running on the same data buckets. REPLICATE TO A TARGET ## Other targets Gluesync delivers to - [Replicate to Aerospike](/solutions/replicate-to-aerospike/) - [Replicate to DynamoDB](/solutions/replicate-to-dynamodb/) - [Replicate to Redshift](/solutions/replicate-to-redshift/) - [Replicate to Amazon S3 & S3-compatible](/solutions/replicate-to-amazon-s3/) - [Replicate to Cassandra](/solutions/replicate-to-cassandra/) - [Replicate to Kafka](/solutions/replicate-to-kafka/) - [Replicate to Cosmos DB](/solutions/replicate-to-cosmos-db/) - [Replicate to Azure Data Lake](/solutions/replicate-to-azure-data-lake/) - [Replicate to ClickHouse](/solutions/replicate-to-clickhouse/) - [Replicate to CockroachDB](/solutions/replicate-to-cockroachdb/) - [Replicate to file stores](/solutions/replicate-to-file-stores/) - [Replicate to BigQuery](/solutions/replicate-to-bigquery/) - [Replicate to Google Cloud Storage](/solutions/replicate-to-google-cloud-storage/) - [Replicate to Google Pub/Sub](/solutions/replicate-to-google-pubsub/) - [Replicate to GridGain](/solutions/replicate-to-gridgain/) - [Replicate to Db2](/solutions/replicate-to-db2/) - [Replicate to Informix](/solutions/replicate-to-informix/) - [Replicate to MariaDB](/solutions/replicate-to-mariadb/) - [Replicate to SQL Server](/solutions/replicate-to-sql-server/) - [Replicate to MongoDB](/solutions/replicate-to-mongodb/) - [Replicate to MySQL](/solutions/replicate-to-mysql/) - [Replicate to Oracle](/solutions/replicate-to-oracle/) - [Replicate to PostgreSQL](/solutions/replicate-to-postgresql/) - [Replicate to RavenDB](/solutions/replicate-to-ravendb/) - [Replicate to Redis](/solutions/replicate-to-redis/) - [Replicate to SAP ASE](/solutions/replicate-to-sap-ase/) - [Replicate to SAP HANA](/solutions/replicate-to-sap-hana/) - [Replicate to ScyllaDB](/solutions/replicate-to-scylladb/) - [Replicate to SingleStore](/solutions/replicate-to-singlestore/) - [Replicate to Snowflake](/solutions/replicate-to-snowflake/) - [Replicate to Solace PubSub+](/solutions/replicate-to-solace/) - [Replicate to Vertica](/solutions/replicate-to-vertica/) - [Replicate to YugabyteDB](/solutions/replicate-to-yugabytedb/) ## Evaluate Gluesync with your Couchbase cluster Start a trial on your infrastructure, or talk to MOLO17 about your sources, your buckets, and the collection layout that fits your apps. [Start a Gluesync trial](/get-gluesync/) [Talk to MOLO17](/contacts/)