MongoDB to MongoDB: How to Move Your Data

Syncing MongoDB to MongoDB copies documents between two clusters, which teams do to refresh a staging environment from production, migrate between hosting providers, or feed a reporting cluster that should not carry application load. Airbyte will do it without code, but you should know one thing first, because it surprises almost everyone: this is not a clone.

The destination does not reproduce your documents in their original shape. It wraps each one in an Airbyte envelope, and anything reading the target collection has to unwrap it.

What actually lands in the target collection?

Each stream is written to its own collection, and each document in that collection contains three fields. There is an _id assigned to each processed document, stored as a String. There is _airbyte_emitted_at, a Timestamp recording when the event was pulled from the source. And there is _airbyte_data, an Object holding your actual document.

Three consequences follow, and they decide whether this pipeline suits your use case.

Your original document identifier is not the collection's identifier any more. Airbyte assigns a new String _id, and your own _id sits inside the data object. Any query, index, or application code targeting the top-level _id will not behave as it did on the source.

Every query needs rewriting to reach into the data object. A find on a top-level field becomes a find on that field nested one level down, and every index you rely on has to be recreated against the nested path.

And because the destination stores the payload as an Object rather than reconstructing the original BSON document, it is worth verifying on a sample how your specific types survive the round trip before you depend on the result.

So this is a good tool for landing MongoDB data somewhere for processing, and a poor tool for producing a drop-in replica that an existing application can point at unchanged. If you need the latter, MongoDB's own tooling for dumps, restores, and cluster-to-cluster sync is the right instrument, and Airbyte is not trying to compete with it.

Choosing a sync mode without deduplication

The MongoDB destination supports full refresh and incremental append, along with namespaces. It does not support incremental append with deduplication.

For the environment-refresh case, which is the most common reason to run this pipeline, full refresh overwrite is the natural fit. You want the target to match the source at a point in time, and a clean replacement gives exactly that.

For an ongoing feed, the absence of deduplication matters. An updated document arrives as an additional entry rather than replacing the earlier one, so the target accumulates versions and your consumer has to pick the most recent using the emitted timestamp. That is workable, but it is a design decision to make deliberately rather than discover.

Setting up both clusters

On the source side, the MongoDB connector reads the oplog for incremental syncs, so your deployment must be a replica set or an Atlas cluster rather than a standalone instance. Views, capped and clustered collections, and system collections are not replicated. Create a dedicated read-only user with a read role across the databases you want.

On the destination side you need a MongoDB server and a user able to create collections and write documents, and Airbyte recommends creating a user specifically for this. Choose or create the target database in advance. You can configure either a standalone instance, supplying host, port, and whether to use TLS, or a replica set by supplying its server addresses.

One constraint applies specifically to Airbyte Cloud: it only supports connecting to your MongoDB instance with TLS encryption. On Open Source you have more latitude, though there is little reason to move production data unencrypted between clusters.

Frequently asked questions

Will my documents look the same in the target cluster?

No. Each document is wrapped, with your original document held inside an _airbyte_data object alongside a new _id and an emitted timestamp. Queries and indexes need rewriting against the nested path.

Can I use this to migrate an application between clusters?

Not as a drop-in replica, because the document shape changes. For a true migration, MongoDB's own dump, restore, and cluster sync tooling is the right choice.

How do I avoid duplicate documents?

There is no deduplicated sync mode on this destination. Use full refresh overwrite where that fits, or have your consumer select the latest version using the emitted timestamp.

Does Airbyte Cloud require TLS?

Yes. Airbyte Cloud only supports connecting to MongoDB with TLS encryption. Open Source deployments have more flexibility.

Get your MongoDB data into MongoDB

Expect wrapped documents rather than a clone, use full refresh for environment copies, and reach for MongoDB's own tooling if you need a true migration. For moving the same data somewhere queryable instead, see our guides to MongoDB to PostgreSQL and MongoDB to ClickHouse.

Start syncing now →