PostgreSQL to MongoDB: How to Move Your Data

Moving PostgreSQL to MongoDB runs against the direction most of this series covers, and it is worth being clear about why you would. Not for analytics, because MongoDB is not a warehouse. This pipeline exists to serve documents to an application: a denormalised read model that a service can fetch by key without joining five tables on every request, or a staged migration towards a document model.

This guide covers the managed path with Airbyte, using change data capture so deletes and updates both arrive. The decision that determines whether the result is any good is made in PostgreSQL rather than in MongoDB, and it is about what shape a document should be.

PostgreSQL to MongoDB at a glance:

Why move data from PostgreSQL to MongoDB?

Two situations account for most of these pipelines, and neither is analytics.

The first is a read model. An application endpoint needs a customer with their orders, addresses and preferences, and assembling that from five normalised tables on every request is expensive. Precomputing it as a document that MongoDB returns by key moves the join cost off the request path and onto a pipeline.

The second is a migration in progress. The application is moving to a document model, and the pipeline keeps MongoDB current while traffic gradually shifts. Here the document design is the new schema rather than a convenience, so it deserves proportionate care.

What do you need before you start?

The PostgreSQL side has the prerequisites that matter, and one of them can affect the health of your source database:

Logical replication enabled. Change data capture on PostgreSQL reads the write-ahead log through a logical replication slot, which means the server has to be configured for it. On managed services this is usually a parameter change and a restart rather than something you can toggle live.

A replication slot and a publication. The slot holds Airbyte's position in the log and the publication defines which tables are included. Both are created on the source and both are yours to manage.

Monitoring on that slot. This is the item to take seriously. PostgreSQL retains write-ahead log segments that a replication slot has not yet confirmed, so a connection that is paused, broken or forgotten causes WAL to accumulate on the source. Left long enough that fills the disk, and it fills the disk of the database serving your application rather than anything belonging to Airbyte.

A MongoDB user that can create collections and write documents. Airbyte recommends creating a user specifically for this purpose, and you will need an existing or new database to hold the synced data. The MongoDB destination documentation lists the configuration fields, and an SSH tunnel is available if the cluster is not directly reachable.

If your organisation restricts inbound traffic by IP, add the Airbyte Cloud IP addresses to the allow list on both systems before you begin.

How do you build a PostgreSQL to MongoDB pipeline in Airbyte?

Step 1: Design the document, then build it in Postgres

Decide what one document should contain, then create a view in PostgreSQL that produces exactly that, using its JSON functions to embed the related data. A customer view that carries its orders as an embedded array is a real document. A customers table replicated one row per document is a relational table living in MongoDB, which gets you the flexibility of neither system.

Step 2: Configure the PostgreSQL source

Click Sources in the left navigation, then New Source, and select Postgres, following adding a source. Supply the host, port, database, schema and credentials, and choose logical replication as the replication method, supplying your slot and publication names. Note that change data capture reads tables rather than views, so if you took the view approach in step 1 you will be using cursor-based incremental on it instead, and should plan deletes accordingly.

Step 3: Configure the MongoDB destination

Click Destinations, then New Destination, and select MongoDB, following adding a destination. Supply the host, port, database and credentials for the user you created, or use an SSH tunnel if the cluster sits inside a private network. Point it at a database dedicated to synced data rather than one your application already writes to, so the pipeline cannot collide with application collections.

Step 4: Create the connection and choose sync modes

Click Connections, then New connection, select your streams and a sync mode per stream. If the application reads these collections live, think about which mode is safe to run underneath it, because a mode that replaces collection contents behaves very differently from one that appends when something is querying at the same time.

Run against one stream first and look at the resulting documents in MongoDB before extending. Document shape is the thing most likely to be wrong, and it is far cheaper to discover that on one collection than on twenty.

Why is a table row a poor document?

Because the point of a document database is that a single fetch returns everything the application needs. A relational schema deliberately splits that across tables and reassembles it with joins, which is exactly the work you are trying to avoid by moving to MongoDB in the first place.

Replicate tables one to one and you land normalised collections with foreign keys but no foreign key support, no joins worth using, and none of the transactional guarantees Postgres was giving you. That is a strictly worse position than either database on its own, and it is the default outcome if nobody designs the document.

So do the assembly in PostgreSQL, which is very good at it. Build a view per document type using JSON aggregation, keep the embedded arrays bounded, and remember that a document has a size limit, so a customer with fifty thousand orders is a document design problem rather than a pipeline one.

What happens if the pipeline stops?

This deserves its own section because the consequence lands on your production database rather than on the pipeline. A logical replication slot marks the oldest position a consumer still needs, and PostgreSQL will not discard write-ahead log segments beyond it.

So if the connection is paused for a sprint, or fails repeatedly over a holiday, or someone deletes the Airbyte connection without dropping the slot, WAL accumulates. On a busy database that can consume disk quickly, and the failure mode is a production outage rather than a stale collection.

Two habits prevent it. Monitor replication slot lag alongside your other database metrics and alert on it, treating it as a database health signal rather than a pipeline one. And make dropping the slot part of your decommissioning checklist, because an abandoned slot is the version of this problem nobody is watching for.

Frequently asked questions

Should I replicate tables directly into MongoDB?

Usually not. A flat row makes a poor document. Build a view in PostgreSQL that assembles the document you want, using its JSON functions to embed related data, and sync that.

Why is my PostgreSQL disk filling up?

An unconsumed logical replication slot. PostgreSQL retains write-ahead log beyond the slot's position, so a paused or abandoned connection causes WAL to accumulate. Monitor slot lag and drop slots you no longer use.

Can I use CDC with a PostgreSQL view?

No. Change data capture applies to tables rather than views, so a view-based document approach uses cursor-based incremental sync instead, which means planning separately for deletions.

Is MongoDB a good analytics destination?

No, and that is not what this pipeline is for. Use it to serve documents to an application. For analysis, send PostgreSQL to a warehouse or lakehouse instead.

Can I do this without writing code?

The Airbyte setup is entirely UI-driven. You will want to write the PostgreSQL views that shape your documents, which is where the design work on this pipeline actually sits.

Get your PostgreSQL data into MongoDB

Design the document before you configure anything, build it as a view in PostgreSQL, and use a MongoDB database dedicated to synced data. Then monitor your replication slot as a database health metric, because the worst failure on this pipeline is not a stale collection, it is a full disk on the database serving your application.

Airbyte's connector catalog includes 600+ pre-built connectors, so the same PostgreSQL source can feed a warehouse alongside this one. For the pipeline in the opposite direction, see MongoDB to PostgreSQL, and for PostgreSQL into a lakehouse, PostgreSQL to Databricks.

Start syncing now →