Canonical: https://molo17.com/solutions/replicate-to-mongodb/ Markdown mirror: https://molo17.com/solutions/replicate-to-mongodb/index.md Title: Replicate to MongoDB in real time with Gluesync | MOLO17 Description: Real-time replication to MongoDB from Oracle, SQL Server, PostgreSQL, and MySQL, with batched native SDK writes to collections and Atlas support. Start a trial. [Solutions](/solutions/) Replicate to MongoDB SOLUTION · REPLICATE TO MONGODB # Real-time data replication to MongoDB from your relational and operational databases **Committed changes from your relational systems land in MongoDB collections continuously, in optimized batches through the native driver, instead of a periodic export and reload.** Gluesync by MOLO17 captures changes from Oracle, SQL Server, PostgreSQL, MySQL, IBM i, and other [heterogeneous sources](/integrations/?target=MongoDB#integration-finder) with a dedicated agent per database, then writes documents to MongoDB through a target agent built on the official MongoDB Kotlin SDK. Snapshots load each collection first, CDC follows continuously, and Core Hub, the Gluesync control plane, runs every pipeline from one web UI and REST API. Self-managed clusters and MongoDB Atlas are both supported. [Start a Gluesync trial](/get-gluesync/) [Talk to us](/contacts/) WHO THIS IS FOR ## Teams that need MongoDB to reflect the systems of record now, not after the next export - Application architects who turn normalized tables into document models, and want field shapes, arrays, and document identifiers set deliberately instead of maintained in sync code - Data platform leads who want one Core Hub feeding MongoDB and every other system from one place, backed by [best-in-class enterprise support, rated 4.9/5 by customers](/support/#customer-ratings) - Platform engineers running self-managed clusters or MongoDB Atlas, who need TLS, DNS seed list discovery, and the authentication database handled in one agent configuration - Engineers replacing a Kafka Connect MongoDB sink or nightly export scripts who want [every source](/integrations/?target=MongoDB#integration-finder) delivered to MongoDB by one product, with snapshots and monitoring built in THE PROBLEM ## MongoDB data that is exported on a schedule drifts from the source Document databases that serve applications or search are usually loaded from nightly exports, or from application code that writes to both systems. The copy drifts from the system of record between runs, and each new source adds another job to maintain. Teams looking for real-time MongoDB ingestion or a MongoDB CDC pipeline usually compare a Kafka Connect MongoDB sink, commercial replication such as Striim or Qlik Replicate, managed ELT from Fivetran or Airbyte, or scripts they maintain themselves. Gluesync addresses that with **per-agent CDC into MongoDB**. A source agent reads each database's native change mechanism, Core Hub routes the changes, and the MongoDB target agent applies them to collections through the native driver. Oracle to MongoDB, SQL Server to MongoDB, and PostgreSQL to MongoDB pipelines share the same model, the same snapshot, and the same operations. HOW IT WORKS ## How Gluesync writes to MongoDB ### The write path: the native MongoDB Kotlin SDK The MongoDB agent uses the official MongoDB Kotlin SDK for connectivity and high availability. It discovers cluster nodes automatically and balances across them, with TLS. It is a target agent: it receives changes from any Gluesync source agent and applies them to your collections in real time. - **Direct application:** snapshot and CDC flows write straight into collections, with no intermediate file buffers between Core Hub and MongoDB. - **Connection modes:** connect to a single server with Direct connection, to a replica set by name, or to a sharded cluster, depending on the topology. ### Optimized batches, never row by row Gluesync never writes one document at a time to MongoDB. Incoming changes are grouped into chunks and sent to the cluster as batched writes, which cuts network round-trips and keeps the load on the primary predictable. The batch size is configurable per entity, so you can push throughput while a snapshot seeds a large collection and keep write bursts small once applications read from MongoDB at full load. ### Documents, identifiers, and duplicate rows - **Duplicate keys:** MongoDB rejects a duplicate on `_id` and on a unique secondary index. Upsert, the default On duplicate key setting, overwrites the existing document with the incoming one. Skip keeps the existing document and reports the skipped keys in Notifications Hub. Fail stops the entity so someone can review it. Core Hub checks each collection when the entity starts and tells you which behavior applies to it. - **Custom document keys:** compose each document identifier from source fields, with a separator, a prefix, a suffix, and the field order you choose. The key applies to new and to existing documents. - **Field shape:** relational columns map to BSON numbers, strings, binary data, and dates. Arrays and nested documents are written to match the field definition of the target. ### Snapshot first, then continuous CDC - **Seed, then stream:** full snapshots load each collection before CDC takes over from the source agent's change mechanism. - **Two-way sync:** Enable Recursion Protection, off by default, stops changes from being applied back to their origin when two-way sync is configured on the same collection. - **Resume:** an interrupted snapshot resumes from its last saved state when you start the entity again. ### What your MongoDB admin sets up The agent needs a user with read and write access to the target database. For the full setup, see the [MongoDB target setup guide ↗](https://docs.molo17.com/gluesync/latest/agents/mongodb-target.html). 1. Create a user with read and write access to the target database. If the user is defined in another database, such as `admin`, enter that database as the Auth Database. 2. In Core Hub, enter the hostname or IP address, the port (27017 by default), and the database name. 3. For TLS, enable it and upload the certificate file in the host credentials. 4. For MongoDB Atlas, turn on Use DNS Seed List and use the cluster's `.pem` certificate. Atlas hostnames resolve through the SRV record. ### Architecture around Core Hub Lightweight agents sit close to each source. Core Hub orchestrates them through its web UI and REST APIs and routes changes to the MongoDB target agent. A pipeline groups a source agent, the MongoDB agent, and the entities they replicate, and Core Hub and agents deploy with Docker, Docker Compose, or Kubernetes, on-premises or in any cloud next to Atlas. [Explore the general CDC streaming architecture →](/solutions/cdc-streaming/) WRITE OPTIONS ## The MongoDB target agent: one agent for every cluster shape MongoDB has one Gluesync target agent. It writes optimized batches directly to collections for both the snapshot and CDC, so the decisions are the document identifiers, the duplicate-key rule, and the connection mode. | Agent | Write technique | Versions | Best for | | --- | --- | --- | --- | | [MongoDB agent ↗](https://docs.molo17.com/gluesync/latest/agents/mongodb-intro.html) | Official MongoDB Kotlin SDK with automatic node discovery and TLS; optimized batched writes applied directly to collections for snapshot and CDC | MongoDB 3.0 and later; replica sets, sharded clusters, and MongoDB Atlas | Document read models and AI retrieval stores fed from relational sources. Set custom document keys and the duplicate-key rule per entity, and use Enable Recursion Protection when two-way sync touches the same collection. | SOURCES AND TOPOLOGIES ## Feed MongoDB from the systems of record you already run Any Gluesync source agent can feed MongoDB, each with its own native capture technique. Open the [integrations finder with MongoDB pre-selected](/integrations/?target=MongoDB#integration-finder) to see every source that pairs with it. One Core Hub runs Oracle to MongoDB, SQL Server to MongoDB, and PostgreSQL to MongoDB pipelines side by side, with the same snapshot, monitoring, and duplicate-key settings for each. Gluesync keeps pace with your change volume at any scale. [MOLO17 Professional Services](/solutions/professional-services/) can help design the document model and the keys with your team. - Oracle to MongoDB from the redo logs through LogMiner or XStream, with relational rows mapped to documents: see [Oracle CDC](/solutions/oracle-cdc/) - SQL Server to MongoDB through Change Data Capture or Change Tracking: see [SQL Server CDC](/solutions/sql-server-cdc/) - PostgreSQL to MongoDB from the write-ahead log: see [PostgreSQL CDC](/solutions/postgresql-cdc/) - IBM i (AS/400) to MongoDB through the native journal APIs: see [IBM i CDC](/solutions/ibm-i-cdc/) FAIR, HIGH-LEVEL COMPARISON ## Where Gluesync fits among MongoDB ingestion approaches | Approach | What buyers usually get | Where Gluesync fits | | --- | --- | --- | | Kafka Connect with a MongoDB sink connector | Open-source capture into Kafka topics, then a MongoDB sink that writes documents. You run Connect, offsets, and the topic-to-collection mapping | Changes applied to MongoDB collections by key, with no Kafka cluster in the path. Kafka stays available as another target. Read the [Debezium alternative](/solutions/debezium-alternative/) comparison | | Fivetran and Airbyte | Managed or open-source ELT with destination connectors on a schedule. Change capture differs by source connector | Log-based capture for each source engine and continuous batched writes into MongoDB, operated from one Core Hub with MOLO17 enterprise support | | Striim and Qlik Replicate | Commercial replication with MongoDB among its targets. Capture and load options vary by product and version | Agents deployed next to each source, native capture per engine, and one Core Hub for every pipeline that writes into MongoDB | | Application dual writes | Services write to the relational database and to MongoDB in the same code path. Every service owns retries, ordering, and failure handling | Changes are captured from the database itself, so application code stays as it is. The [customer 360](/solutions/customer-360/) pattern shows one target fed from several systems | | Scripts with mongoimport or batch exports | Full control for one-off loads. Your team owns the extracts, file formats, upserts, and reruns | A snapshot followed by continuous changes, with duplicate-key handling and monitoring in Core Hub and no pipeline code to maintain | RELATED CONTENT ## MongoDB replication reading and related pages - [Batch ETL vs real-time data replication: how to choose](/blog/batch-etl-vs-real-time-data-replication/) - [MongoDB CDC: capture with Change Streams](/solutions/mongodb-cdc/) - [AI and RAG data supply: keep retrieval stores current](/solutions/ai-rag/) - [Customer 360: one shared target from several systems](/solutions/customer-360/) - [MongoDB target setup guide ↗](https://docs.molo17.com/gluesync/latest/agents/mongodb-target.html) - [Custom document keys for NoSQL targets ↗](https://docs.molo17.com/gluesync/latest/core-hub/custom-document-keys.html) - [Data type mapping across type systems ↗](https://docs.molo17.com/gluesync/latest/core-hub/data-type-mapping.html) - [Write strategies: optimized batches ↗](https://docs.molo17.com/gluesync/latest/core-hub/write-strategies.html) FAQ ## MongoDB replication questions What does replicating to MongoDB with Gluesync involve? A Gluesync source agent captures committed changes from your database through its native change mechanism, Core Hub routes them, and the MongoDB target agent writes them to collections continuously after a snapshot loads each collection. How does Gluesync write to MongoDB? Through the official MongoDB Kotlin SDK, which discovers cluster nodes and supports TLS. Snapshot and CDC flows are grouped into optimized batches and written directly into collections, with no intermediate files. Which sources can replicate to MongoDB? Any Gluesync source agent, including Oracle, SQL Server, PostgreSQL, MySQL, MariaDB, IBM i, and Couchbase. The integrations finder on our website lists every pairing. How are duplicate documents handled? MongoDB rejects duplicates on \_id and on unique secondary indexes. Upsert, the default On duplicate key setting, overwrites the existing document with the incoming one, while Skip keeps it and reports the skipped keys. Can I control the document identifier? Yes. Custom document keys compose each identifier from source fields with a separator, prefix, suffix, and field order, and the key applies to new and existing documents. Which MongoDB versions and deployments are supported? MongoDB 3.0 and later, on self-managed replica sets and sharded clusters, in any public cloud, and on MongoDB Atlas. Atlas connections use the DNS seed list option together with the cluster's .pem certificate. How does two-way sync avoid echoing changes back? Enable Recursion Protection, which is off by default, stops changes from being applied back to their origin when two-way sync is configured on the same collection. 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 Couchbase](/solutions/replicate-to-couchbase/) - [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 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 MongoDB clusters Start a trial on your infrastructure, or talk to MOLO17 about your sources, the document model, and the duplicate-key rules you need. [Start a Gluesync trial](/get-gluesync/) [Talk to MOLO17](/contacts/)