Skip to content
adapters.io

MongoDB to Snowflake connector, migration and CDC tools compared, and the schema the free one never builds

Twelve ways to get MongoDB collections into Snowflake, and one fact that decides the budget before any feature comparison. Snowflake's own MongoDB connector creates a destination table with two columns, id and data, so the document lands as a payload rather than as columns your BI tool can read. Four of its sibling connectors hand you a schema. This one hands you the modeling job. Everything here was read from Snowflake's connector documentation on 9 September 2026.

Try the live demo

No credit card required.

Field mapping auto-plugged · tap a port to rewire

5 sample records ready

Vendor documentation read 9 September 2026 · Last updated September 2026

Which MongoDB to Snowflake connector should you use?

One question decides it, and it is not latency or price. It is who writes the schema. Snowflake's first-party Openflow connector for MongoDB does the ingestion well, following the change stream for inserts, updates and deletes, but it lands each document whole into a table with two columns, id and data. Nothing your BI tool can chart exists until someone writes views over that payload. If your team will do that modeling, the first-party connector is the cheapest correct answer. If you need typed, flattened, analyst ready columns delivered to you, that flattening is most of what Fivetran, Estuary, Streamkap and Hevo are actually selling on this route. Two hard prerequisites can remove the free option before you get that far: standalone MongoDB instances are not supported, and the connector needs a cluster wide read role.

One scoping note before anything else. If this is a single extract of a few collections for one analysis, the cheapest correct answer on this page is mongoexport plus COPY INTO, and no vendor will tell you that. For the ongoing warehouse load pattern across every source see Snowflake ETL tools, and for the wider one-time cutover category, data migration tools.

Snowflake ships one connector per source, and the MongoDB one is the odd one out

Openflow is one product family with one connector per source. Put the MongoDB connector next to the PostgreSQL, MySQL, SQL Server and Salesforce connectors and they answer the same operational questions in different ways, without any page acknowledging the others. On the row that decides your budget, the MongoDB connector is alone: it is the only one that does not produce a schema. We read all five documentation sets on 9 September 2026. The last column is what we would ship.

What is at stake What Snowflake's docs say Why it matters to a buyer What we would ship
What actually lands in Snowflake The Openflow MongoDB connector creates a destination table with two columns: id, described as the "ID of the MongoDB document", and data, described as "The payload of the document". The PostgreSQL, MySQL and SQL Server connectors replicate the source table column for column, and the Salesforce connector produces typed columns plus generated views. This is the single biggest cost difference on the route and almost nobody states it plainly. Four connectors in the family hand you a queryable schema. The MongoDB one hands you a payload and leaves the modeling to you. A buyer comparing "Snowflake has a free first party connector" against a paid pipeline is not comparing the same deliverable, because most of what the paid pipeline sells on this route is the flattening the free one declines to do. Budget the view layer as project work, not as cleanup
What detects a change Snowflake documents that the MongoDB connector "listens to the MongoDB change stream to read the journal document-level changes (inserts, updates, deletes)". The MySQL connector reads the binary log, the SQL Server connector uses SQL Server Change Tracking, the PostgreSQL connector requires wal_level set to logical plus a publication, and the Salesforce connector compares timestamp fields. Five sources, four genuinely different change mechanisms, one product family. MongoDB is on the good side of this line: a change stream is a real ordered feed, so you see deletes as events rather than inferring them. The catch is that the feed is a property of the deployment rather than a setting, which is why the prerequisite two rows down is a hard stop rather than a configuration change. Treat MongoDB collections as a true event feed, not a snapshot
The metadata columns you can rely on For PostgreSQL, Snowflake documents that the connector "adds metadata columns to every replicated row (_SNOWFLAKE_UPDATED_AT, _SNOWFLAKE_INSERTED_AT, _SNOWFLAKE_DELETED)". MySQL and SQL Server document the same _SNOWFLAKE_DELETED soft delete flag. Salesforce instead uses Salesforce's own isDeleted field. The MongoDB destination table is documented as id and data. A warehouse team that standardizes on "filter _SNOWFLAKE_DELETED = FALSE" across every source will find that convention holds for three connectors, is spelled differently on a fourth, and is not part of the documented table shape on the fifth. There is no single query you can write once and run against every Openflow source, even though one vendor built all of them and owns the destination. Write one normalizing view per source rather than one shared filter
The deployment prerequisite 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". The minimum supported version is MongoDB 4.4. The database connectors ask you to change a setting instead: a binlog format, Change Tracking, or wal_level. This is a different class of blocker and it is the one that kills projects quietly. A binlog setting is a config change and a restart. A standalone MongoDB becoming a replica set is a topology change to a production database, and on a self hosted single node it can mean new infrastructure. Teams discover this after the connector has already been chosen and the quarter has already been planned. Check the deployment topology in week one, before shortlisting anything
The permission the connector needs The connector opens a cluster level change stream, and Snowflake documents that this requires "the readAnyDatabase role on the admin database", with the MongoDB authentication source set to admin. You are asking your security reviewers to grant read across every database on the cluster so that one pipeline can sync a handful of collections. That is a defensible grant, but it is not the least privilege story most reviewers expect, and it is far broader than the per table grants the relational connectors need. In a regulated US business this is the row that adds weeks, not the throughput numbers. Take the access request to security before the technical evaluation
Whether you can scale it out Snowflake documents that for this connector "The runtime size must be at least Medium", that Min nodes and Max nodes are both set to 1, and that "The connector doesn't support multi-node Openflow runtimes". The recommended Snowflake warehouse starting size is also Medium. Two consequences a buyer should price. There is a compute floor before any document moves, so the free connector is not free to run. And the only lever for a large collection is a bigger single node, because adding nodes is not an option. If your throughput ceiling arrives, the answer is vertical, and vertical eventually stops. Load test your largest collection before committing the quarter

None of this makes the documentation wrong, and we would still start with it. It makes the point that a connector family is a set of separately built products rather than one consistent contract, even when one vendor owns all of them and owns the destination. The first row is the one to act on today, because "we have a free first party connector" and "we have analyst ready tables" are two different project states and only one of them was funded. The same comparison for the relational sources is on Postgres to Snowflake migration tools, MySQL to Snowflake migration tools and SQL Server to Snowflake migration tools.

The five mechanisms buyers keep confusing

Most confusion on this route comes from treating "MongoDB to Snowflake" as one thing. It is five different products with different owners, different bills and different failure modes. Four of them read the same MongoDB change stream, so the technical mechanism is often identical and the deliverable is not.

Mechanism Owner How it moves data Who it is for What to watch
Openflow connector Snowflake Full initial copy per collection, then follows the MongoDB change stream and merges document level changes into a two column table. Teams on a replica set or Atlas who are comfortable modeling documents in Snowflake SQL themselves. It lands a payload, not a schema. Medium runtime floor, single node only.
Managed ELT pipeline Fivetran, Estuary, Streamkap, Hevo, Rivery Reads the same change stream, then flattens documents into typed columns and adapts as new fields appear. Teams who want analyst ready tables and treat schema drift as somebody else's problem. Metered on rows or events, so the backfill month is the expensive one.
Open source CDC You, on Debezium or Kafka Connect Tails the change stream into a broker, then a sink writes to Snowflake on your own schedule and shape. Teams already running Kafka who want full control of the document to column contract. No license cost, real operational cost. Someone owns the offsets at 3am.
Scripted export and load You, on mongoexport plus COPY INTO Dumps collections to files in stage, then loads them. Point in time, with no change tracking at all. One time analyses and proofs of concept where nothing needs to stay current. Stale the moment it finishes. Fine for a question, wrong for a dashboard.
Mapped sync (Adapters) Adapters You declare the document paths that matter, we land them as typed columns and keep the mapping under version control. Teams who want typed output without metered pricing and without owning a Kafka cluster. We are not a general purpose streaming platform. Sub second latency is not our claim.

MongoDB to Snowflake connectors and CDC tools compared

Pricing models rather than price tags, because every vendor here except us either quotes or meters, and any figure printed on this page would be stale within a quarter. Snowflake publishes no separate fee for the Openflow connector, and it does have a compute floor, so this page says that instead of inventing a number. Where a tool is wrong for a job, the last column says so.

Tool Approach Best for Billing unit What to watch
Snowflake Openflow First party change stream connector, two column destination table Snowflake shops on a replica set who will model documents themselves Snowflake credits for runtime and warehouse, no separate connector fee No flattening, Medium runtime floor, single node, no standalone MongoDB
Fivetran Managed connector with automatic schema handling Teams who want typed tables and predictable operations Monthly active rows History backfill is the largest month you will ever bill
Estuary Flow Streaming CDC with document normalization Low latency needs with nested documents to unpack Data volume plus connector time Field count limits apply to very wide documents
Streamkap Streaming CDC into Snowpipe Streaming Near real time analytics on high change collections Throughput based Newer vendor, so weigh the operational track record
Airbyte Open source or cloud connector, change stream based Teams who want to read and patch the connector code Free self hosted, credits on cloud Self hosting is real infrastructure work, not a checkbox
Debezium plus Kafka Change stream to broker to Snowflake sink Organizations already standardized on Kafka Infrastructure and engineering time You own connector offsets, retries and the schema registry
Hevo Managed pipeline with schema mapping Small teams with no data engineer Events per month Event counting includes updates, which document stores generate freely
Rivery Managed ELT using MongoDB change streams Teams wanting orchestration and loading in one place Credit based Credits are consumed by orchestration too, not only by rows
Matillion Warehouse native transformation with source connectors Shops that want the T to happen inside Snowflake Credit based Strongest at transformation, thinner at document ingestion
Talend Enterprise integration suite Large programs needing governance and lineage Subscription, quoted Weight and cost only pay off at real program scale
mongoexport plus COPY INTO Manual export to stage, then load One time extracts and proofs of concept Free, plus your time No incremental story at all, so it does not become a pipeline
Adapters Declared path to column mapping, incremental sync, per record logs Teams who want typed columns on a flat bill Flat monthly from $49, not metered by rows Not a sub second streaming platform

Six facts worth knowing before you sign anything

2 columns

What the first-party connector creates in Snowflake: id and data. The whole document arrives as a payload, so the schema work is yours.

Snowflake Openflow MongoDB docs, read 9 Sep 2026

Replica set

Snowflake states plainly that standalone MongoDB instances are not supported. The connector needs a replica set or a sharded cluster.

Snowflake Openflow MongoDB docs, read 9 Sep 2026

4.4

The minimum supported MongoDB version. Older production clusters are ruled out of the free route before any feature comparison.

Snowflake Openflow MongoDB docs, read 9 Sep 2026

readAnyDatabase

The role the connector needs on the admin database, because it opens a cluster level change stream rather than a per collection one.

Snowflake Openflow MongoDB docs, read 9 Sep 2026

Medium

The minimum Openflow runtime size and the recommended warehouse starting size. A compute floor exists before a single document moves.

Snowflake Openflow MongoDB docs, read 9 Sep 2026

1 node

Min nodes and max nodes are both 1. Snowflake states the connector does not support multi-node runtimes, so scaling out is not available.

Snowflake Openflow MongoDB docs, read 9 Sep 2026

Eight ways this pipeline goes wrong while every check stays green

A document pipeline rarely fails loudly, and a schemaless source makes it quieter still. The run log is clean, the row count went up, and a number somewhere is wrong. These are the eight we would check for on any existing MongoDB to Snowflake pipeline before believing a single figure it produces.

The failure What you see What is actually happening
The payload column nobody modeled Sync succeeds, row counts match the collection exactly Every document is in one column and no dashboard can read it. The pipeline is genuinely finished and the project is not, because the deliverable was analyst usable tables.
A new field nobody notices No error, no schema change, no alert In a document store a new field is just a document. It lands inside the payload and stays invisible until someone asks why a metric is missing for records created after a release.
A field that changed type Loads keep succeeding A field that was a number in old documents and a string in new ones sits happily in the same payload column. The break appears later, in a cast inside a view, long after the deploy that caused it.
The secondary read that fell behind Data arrives, freshness looks plausible Directing reads at a secondary reduces load on the primary, which Snowflake suggests, but replication lag on that secondary becomes pipeline lag. Nothing reports an error while your numbers quietly age.
The resume token that expired The connector restarts and carries on Change streams resume from a token in the oplog. If the pipeline is down longer than the oplog window, that position is gone and the gap is silent unless you reconcile counts against the source.
The identifier setting changed after go live Configuration saved, connector still running Snowflake warns not to change Object Identifier Resolution once ingestion has begun because it breaks existing ingestion and requires a new connector instance. Changing it is a one way door disguised as a dropdown.
Arrays multiplying rows Every job green, totals inflated The first FLATTEN over an array of line items turns one order into many rows. Join that to a payments table and revenue is overstated. The pipeline was correct throughout, the model was not.
A collection that outgrew one node Backlog grows, no failure With multi-node runtimes unavailable, a collection that exceeds what a single node can keep up with simply falls further behind each day. There is no error state for a pipeline that is merely losing the race.

The pattern behind seven of these eight is the same: nothing in a document store forces a shape, so nothing in the pipeline can object to a shape changing. The guard is reconciliation on a schedule rather than trust in a green run log. The equivalent list for a relational source, where the database does enforce a shape, is on change data capture tools.

Six steps that decide whether this project works

Step 1

Confirm the deployment shape first

Before evaluating a single vendor, check whether MongoDB runs as a replica set, a sharded cluster or a standalone node. Atlas is already a replica set. A self hosted single node is not, and the first-party connector will refuse it, which changes the shortlist and the budget on day one.

Step 2

Decide who writes the schema

This is the real fork on this route. If your team will model documents into views in Snowflake, the first-party connector is a sound choice and the cheapest. If you need typed columns handed to you, you are buying flattening, and that is what the managed pipelines charge for. Decide before you compare price, because the two options do not deliver the same thing.

Step 3

Get the access grant approved early

A cluster wide read role on the admin database takes longer to approve than to configure. Raise it with security in the first week with the reason attached, namely that a cluster level change stream needs it. Chasing this after the technical work is done is how a two week project becomes a two month one.

Step 4

Pick the paths that matter, then flatten deliberately

Do not try to project every path in every document. List the fields your reports actually use, write one view per collection that pulls those out with typed casts, and leave the rest in the payload. Arrays need care: flatten them into their own child views rather than joining them straight into an order level table.

Step 5

Reconcile counts before anyone trusts a number

Run a count per collection against MongoDB and against the landed table, on the same as-of moment, and repeat it on a schedule. This is the only check that catches an expired resume token, a lagging secondary or a silent gap, because none of those produce an error message.

Step 6

Load test the largest collection, not the average one

With scaling limited to a single larger node, your biggest collection sets the ceiling for the whole pipeline. Run the initial snapshot on it before you commit, time it, and watch whether incremental sync keeps pace afterwards. Finding the ceiling in month three is far more expensive than finding it in week two.

Why US teams fund this project

Product analytics on event documents

Usage events live in MongoDB because the shape changes with every release. Analysts need them next to billing and CRM data in Snowflake, joined on account, without querying the operational cluster.

Ecommerce order reporting

Orders with nested line items and addresses need to become order and line item tables that finance can reconcile against payouts, which means arrays get flattened deliberately rather than accidentally.

Retiring a read replica used for reporting

A secondary kept alive purely so analysts can run queries is a cost and a risk. Moving that workload to Snowflake lets the cluster go back to serving the application only.

Feeding a customer facing dashboard

Snowflake serves concurrent analytical queries far better than a document store, so customer facing metrics get built on landed data rather than run against production collections.

Consolidating after an acquisition

One company on MongoDB and one on Postgres both need to land in the same warehouse. The two connectors behave differently enough that the normalization layer has to be planned, not assumed.

Machine learning feature pipelines

Training sets need stable, typed, historical columns. A payload column that changes shape over time is a poor feature store, so the flattening layer becomes part of the ML platform.

Five jobs where you should not pick us

A comparison page that never says the competition wins is an advert. These are the cases where we are the wrong answer and something on the list above is the right one.

  • You need sub second latency between a document write and a warehouse row. A streaming platform built for that will beat us, and we would rather say so than pretend otherwise.
  • You are already running Kafka and Debezium successfully. Adding a vendor to a working change stream pipeline buys you very little, and you would be paying for a problem you have already solved.
  • You want every path in every document projected automatically, with no declaration from you. Fivetran and Estuary invest heavily in exactly that behavior. We ask you to declare the paths you care about, which is deliberate and is not what everyone wants.
  • This is a single point in time extract for one analysis. Use mongoexport and COPY INTO, spend nothing, and come back when the question turns into a dashboard.
  • Your compliance regime forbids the data leaving your own network entirely. A self hosted open source pipeline is the honest answer there, and no managed vendor including us can meet that constraint.

Four questions to ask any vendor on this list

What exactly lands in my warehouse on day one?

Ask for the destination DDL, not a screenshot of a dashboard. A two column payload table and a set of typed, flattened tables are wildly different deliverables, and the word "connector" covers both. This single question separates most of the price differences on this page.

What happens when a document gains a new field?

There are three honest answers: a new column appears automatically, the field lands inside the payload and waits for you, or the pipeline errors. All three are defensible. Not knowing which one you bought is not, because document shapes change with every product release.

How do deleted documents appear in the destination table?

Ask for the column name and the value. Across Snowflake's own connector family this is spelled _SNOWFLAKE_DELETED on three sources and isDeleted on another, so assume nothing. If the answer is that deletes are not applied, find out now rather than when a count is wrong.

What is the smallest configuration that runs this?

Compute floors matter more than rate cards for small workloads. A connector with a Medium runtime minimum and a Medium warehouse recommendation has a monthly cost even when almost nothing changes, and that baseline can exceed a flat vendor fee for a modest collection.

Related migration and warehouse guides

MongoDB is one source into Snowflake among several. These cover the neighboring database sources whose connectors this page is compared against, the ongoing load pattern once the first sync is running, and the wider one-time cutover category.

Best MongoDB to Snowflake CDC tools for nested documents

Which tools flatten nested documents for you, and what each one does when a field changes shape.

Postgres to Snowflake migration tools

The relational sibling connector, where a schema arrives and three metadata columns come with it.

MySQL to Snowflake migration tools

The binlog route, and the prerequisite chain that a managed MySQL host may not let you complete.

Snowflake ETL tools

The ongoing load case across every source, once the first pipeline is running.

Change data capture tools

How change capture differs by source, from change streams to logical replication to polling.

Data migration tools

The pillar above this page, covering one-time cutovers rather than ongoing sync.

Questions buyers ask about MongoDB to Snowflake migration

How do I connect MongoDB to Snowflake?
Snowflake cannot query MongoDB directly, so something has to move the documents. The realistic routes are the first-party Openflow connector for MongoDB, a managed pipeline such as Fivetran, Estuary or Streamkap, an open source change stream reader, or a scripted export. Your MongoDB deployment shape decides which are even available, because the first-party option refuses standalone instances.
Does Snowflake have a native MongoDB connector?
Yes. Snowflake ships an Openflow connector for MongoDB that does a full initial copy of each collection and then follows the MongoDB change stream for inserts, updates and deletes. The important detail is what it produces. It creates a destination table with two columns, id and data, so the document arrives as a payload rather than as typed columns.
What is the best MongoDB to Snowflake connector?
It depends on who writes the schema. If your team is happy to model the documents yourself in Snowflake SQL, the first-party Openflow connector is the cheapest correct answer. If you need typed, flattened columns that BI tools can read without a modeling layer, that flattening work is most of what the paid pipelines are selling, and it is why they cost what they cost.
How does MongoDB to Snowflake CDC work?
Through MongoDB change streams. A change stream is an ordered feed of document level changes that MongoDB exposes on a replica set or sharded cluster, and a connector tails it, turning each insert, update and delete into a merge against the destination table. It is genuine change capture rather than polling, which is why the deployment prerequisite is strict.
Can I connect MongoDB Atlas to Snowflake?
Yes, and Atlas is the easier starting point because Atlas clusters are already replica sets, which is exactly what the change stream requires. The work moves to access and networking: a user with the right cluster wide read role, an allowlist entry for wherever the connector runs, and a decision about whether reads are directed at a secondary node.
How do I flatten MongoDB documents in Snowflake?
With LATERAL FLATTEN over the payload column, plus a view per collection that projects the paths you actually query into typed columns. This is not an optional polish step on the first-party route. The connector lands the whole document in one column, so until somebody writes those views, your BI tool has nothing it can chart.
Does the MongoDB to Snowflake connector handle deletes?
The change stream carries deletes, so the connector sees them. What Snowflake documents for MongoDB destination tables is a two column shape, id and data, rather than the _SNOWFLAKE_DELETED metadata column that the PostgreSQL, MySQL and SQL Server connectors add. Confirm how removed documents appear in your own table before you write a query that assumes either behavior.
How much does MongoDB to Snowflake replication cost?
Three bills, and one of them is a floor rather than a rate. Snowflake documents a minimum runtime size of Medium and a recommended warehouse starting size of Medium for this connector, so there is a compute baseline before a single document moves. Add your pipeline vendor if you use one, plus the storage and query cost of the landed data.
Can I query MongoDB data in Snowflake?
Yes, once it is landed, but not with the SQL you would write against a relational replica. On the first-party route the document sits in a semi structured payload column, so queries use path notation and FLATTEN rather than plain column references. Most teams solve this once by publishing views that hide the paths from analysts.
Should I use Fivetran for MongoDB to Snowflake?
Consider it when you want typed columns without owning the modeling, and when your document shape changes often enough that maintaining your own views is a real cost. Price the first month separately, because the initial history load of a large collection is the biggest month you will ever have. Ask specifically how new fields and removed documents are handled.

For the tool-by-tool view of which pipelines flatten documents for you, read the best MongoDB to Snowflake CDC tools for nested documents. For the wider vendor landscape see the best data integration tools, and for what a cutover of this size really costs, what a data migration really costs.

Land MongoDB documents in Snowflake as columns, not as a payload

Declare the document paths that matter once, run the backfill, then let the same mapping run incrementally with retries, alerts and per-record logs. From $49 a month, not metered by rows.

Try the live demo

No credit card required.