Best MongoDB to Snowflake CDC tools for nested documents, and which ones flatten them for you
10 min read Data engineering The Adapters team
Last updated September 2026
Field mapping auto-plugged · tap a port to rewire
Plug a source port into
Transform on this cable
JSON in
JSON out
5 sample records ready
Almost every tool on this list reads the same thing: the MongoDB change stream. That means the capture mechanism is rarely what separates them, and comparing them on latency or on "supports CDC" tells you very little. What actually separates them is what happens to a nested document the moment it reaches Snowflake. Some hand you typed, flattened columns an analyst can query. One of them, notably the free first-party option, hands you the document whole in a single column and leaves the modeling to your team. Everything about Snowflake's own connectors below was read from their documentation on 9 September 2026.
Key takeaways
- The free connector does not flatten anything. Snowflake's Openflow MongoDB connector creates a destination table with two columns, id and data, where data is "The payload of the document".
- Flattening is what the paid tools sell. On this route, most of the price difference is the document to column contract, not the capture mechanism.
- Ask what happens to a new field. There are three honest answers and all of them are defensible. Not knowing which one you bought is not.
- Arrays are where numbers go wrong. The first careless FLATTEN over line items turns one order into many rows, and revenue is overstated with every job still green.
What is the best MongoDB to Snowflake CDC tool?
The best tool is the one whose output matches who is going to write your schema. If your team will model documents into views inside Snowflake, Snowflake's own Openflow connector is the cheapest correct answer and it captures changes properly. If you need analyst ready tables handed to you, pick a pipeline that unpacks documents on ingestion, because that flattening is real, ongoing engineering work you would otherwise be funding yourself.
That framing sounds like a dodge until you look at what each tool produces. Below is the comparison that actually decides the purchase, and it is not one you will find on a vendor page, because the vendors compare themselves on throughput and connector counts instead.
Which MongoDB to Snowflake tools flatten nested documents?
Four of the eight below unpack documents for you by default. Two leave it to you by design. Two depend on how you configure them. The column that matters most is the third one, what happens when a document gains a field, because in a document store that happens with ordinary product releases rather than as a planned migration.
| Tool | What lands in Snowflake | When a document gains a field | Arrays | Who models it |
|---|---|---|---|---|
| Snowflake Openflow | Two columns: id and data. The whole document arrives as a payload. | Nothing happens. The field is inside the payload and no schema changes. | Untouched. You write the FLATTEN yourself. | You model it |
| Fivetran | Typed columns, with the document unpacked into a table per collection. | A column is added automatically on the next sync. | Unpacked into related tables. | It models it |
| Estuary Flow | Normalized columns, with nested objects unpacked on ingestion. | Picked up and added, within a documented field count ceiling. | Unpacked, subject to that same ceiling. | It models it |
| Streamkap | Streamed columns via Snowpipe Streaming. | Detected in incoming documents and added without a pipeline restart. | Handled during transformation, not left raw. | It models it |
| Airbyte | Raw JSON by default, with normalization as a configured step. | Present in the raw record. Whether a column appears depends on your setup. | Depends entirely on the normalization you configure. | You decide |
| Debezium plus Kafka | Whatever your sink and converter are configured to write. | Flows through the topic. The schema contract is yours to enforce. | Yours to model, in the sink or in Snowflake. | You model it |
| Hevo | Mapped columns, with schema mapping presented in the UI. | Surfaced for mapping, with automatic handling available. | Mapped, with nesting exposed in the mapping step. | It models it |
| Adapters | Only the document paths you declare, as typed columns. | Nothing lands until you add the path, which is the point. | Flattened into a child table when you declare them that way. | You declare it |
Does the Snowflake MongoDB connector flatten documents?
No. Snowflake documents the destination table as two columns: id, described as the "ID of the MongoDB document", and data, described as "The payload of the document". The connector does a full initial copy of each collection and then follows the change stream for inserts, updates and deletes, so the ingestion is genuinely solid. It simply does not attempt to turn a document into columns, and it does not claim to.
This is worth dwelling on because of how it distorts a build versus buy comparison. Put the MongoDB connector next to Snowflake's own connectors for other sources and it is the odd one out. The PostgreSQL connector replicates tables column for column and, in Snowflake's words, "adds metadata columns to every replicated row (_SNOWFLAKE_UPDATED_AT, _SNOWFLAKE_INSERTED_AT, _SNOWFLAKE_DELETED)". The MySQL and SQL Server connectors carry the same soft delete flag. The Salesforce connector produces typed columns plus generated views. Four connectors in one product family deliver a queryable schema. The MongoDB one delivers a payload. We have the full side by side on MongoDB to Snowflake migration tools.
So when someone in a planning meeting says Snowflake has a free first-party MongoDB connector, they are right, and the project is not therefore done. Landing the data and making it usable are two separate pieces of work on this route, and only the first one is free.
How do I flatten MongoDB documents in Snowflake?
With LATERAL FLATTEN over the payload column, plus one view per collection that projects the paths you actually query into typed, named columns. Keep the raw payload table as the landing zone and never point a dashboard at it directly. The views are the contract your analysts consume, which means you can change how you model something without re-ingesting anything.
Two rules save most of the pain here. First, project only the paths that are used. Trying to mirror every field in every document recreates the schema management problem you left MongoDB to avoid, and it breaks the first time a field appears with a different type. Second, give arrays their own views. An order document with an array of line items should become an orders view and a separate order_items view joined on the order id. Flattening line items inside the orders view is the single most common way revenue gets overstated on this route, because one order becomes five rows and every downstream sum inherits the multiplication.
Cast types explicitly in the view rather than relying on inference. A field that arrived as a number in documents written last year and as a string in documents written after a release will sit together in the same payload column without complaint. The cast is where you find out, and you would much rather find out in a view definition than in a board deck. Before you change how a path is projected, it also pays to know which reports depend on it, which is the kind of thing a column level lineage map answers in seconds and a search across dashboards does not.
Is MongoDB change stream CDC different from database CDC?
The mechanism is comparable and the prerequisite is not. A change stream is an ordered feed of document level changes, so like a binary log or a write ahead log it gives you deletes as real events rather than as something you infer from a missing row. In that sense MongoDB is on the good side of the line, and better placed than a source that polls timestamps.
The difference is what it costs to switch on. On MySQL you change a binlog setting. On PostgreSQL, Snowflake requires wal_level set to logical plus a publication. Both are configuration. For MongoDB, Snowflake states that "Standalone MongoDB instances aren't supported" and that the connector "requires a MongoDB deployment running as either a Replica Set or a Sharded Cluster", with a minimum version of 4.4. If you are on Atlas you already meet this, because Atlas clusters are replica sets. If you are running a self hosted single node, you are looking at a topology change to a production database before any pipeline exists. That is a different conversation from a config flag, and it is worth having in week one rather than after a vendor has been chosen.
There is an access dimension too. Because the connector opens a cluster level change stream, Snowflake documents that it needs "the readAnyDatabase role on the admin database". Granting one pipeline read access across every database on a cluster is defensible, but it is broader than the per table grants the relational connectors ask for, and in a regulated US business it is the kind of standing access grant that has to be justified and recorded against a control rather than approved in a chat thread. Raise it early. It takes longer to approve than to configure.
How much do MongoDB to Snowflake CDC tools cost?
Prices move too fast for a page like this to quote them honestly, so here is the part that does not move: the billing unit, and the floor. Fivetran bills on monthly active rows, Hevo on events, Estuary on data volume plus connector time, Rivery on credits. For a document store the events metric deserves particular attention, because applications happily rewrite whole documents on small changes, and every one of those is an event you pay for.
The free option has a floor rather than a rate. Snowflake documents that the MongoDB connector requires a runtime size of at least Medium, recommends a Medium warehouse starting size, and does not support multi-node runtimes, with min and max nodes both set to 1. So there is compute cost before a single document moves, and if a large collection outgrows a single node, the only lever is a bigger node. For a modest collection that baseline can genuinely exceed a flat vendor fee, which inverts the usual assumption that first-party means cheapest. The wider cost picture for a project of this shape is in what a data migration really costs.
Which tool should you actually pick?
Three cases cover most teams. If you are on Atlas, have a data engineer, and your document shapes are reasonably stable, start with the first-party Openflow connector and budget a sprint for the view layer. You will spend less and you will understand your own model, which pays off every time a question about a number comes up.
If your documents change often and nobody owns the warehouse model, buy the flattening. Fivetran, Estuary, Streamkap and Hevo all do it, and the honest comparison between them is about operational track record and billing unit rather than capability. Run each candidate against your messiest collection during the trial, not your cleanest one.
If you want typed columns without metered pricing, declaring the paths you care about is a middle path that suits more teams than it gets credit for. Most warehouses use a small fraction of the fields in a document, and naming that fraction explicitly turns schema drift from an incident into a change request. That is what we built, on a flat monthly price rather than a row count, and the full comparison including where we are the wrong choice sits on MongoDB to Snowflake migration tools.
What to check before you sign
Ask for the destination DDL rather than a demo. A two column payload table and a set of typed tables are different deliverables sold under the same word. Ask what happens when a document gains a field, and get the answer in writing. Ask how a deleted document appears, by column name and value, because across Snowflake's own connector family that is spelled _SNOWFLAKE_DELETED on three sources and isDeleted on another, so no convention is safe to assume. And run a count reconciliation against the source on a schedule from day one, because an expired resume token, a lagging secondary and a silent gap all look exactly like a healthy pipeline from the run log.
If you are landing more than one source into the same warehouse, plan the normalization layer rather than assuming it. The same vendor's connectors do not agree with each other, which we worked through for the relational sources on Postgres to Snowflake migration tools and for the wider category on change data capture tools.
Nested documents into Snowflake, as columns you named
Declare the paths that matter, flatten arrays into their own tables, and keep the mapping in version control. Flat $49 a month rather than a rate that climbs with every document rewrite.
No credit card required.