How to Migrate MongoDB Data to Snowflake

Modern applications generate massive volumes of operational data in MongoDB. But while MongoDB is excellent for handling high-velocity application workloads and flexible JSON documents, it is not designed for large-scale analytical querying and business intelligence.

That is where Snowflake comes in.

By migrating MongoDB data to Snowflake, teams can centralize semi-structured data inside a scalable cloud data warehouse and run faster analytics, reporting, and machine learning workloads. This combination allows organizations to unify operational and analytical systems without sacrificing scalability or flexibility.

According to the Stack Overflow Survey 2025, roughly 25% of developers use MongoDB, making it the most widely adopted NoSQL database globally. Meanwhile, Snowflake reached a $3.8 billion revenue run rate in 2024 with 27% year-over-year growth, reflecting how fast enterprises are consolidating analytics on cloud warehouses.

This post covers three proven methods to migrate MongoDB data to Snowflake, with step-by-step instructions for each, plus a pre and post-migration checklist to keep your data pipeline clean from day one.

Why Move Data from MongoDB to Snowflake

Despite being well suited for handling high-velocity, semi-structured operational data, MongoDB fails to address the growing needs of an organization. The database struggles with analytics, running complex queries, joins, and reports directly to operational databases, thus limiting its functionalities.  

On the other hand, moving data from MongoDB to Snowflake allows teams to separate transactional workloads from analytics. This improves speed and enables scalable insights within no time. Here are a few more reasons why you should consider moving data from MongoDB to Snowflake. 

• Centralized analytics from semi-structured operational data: Snowflake provides a single window for querying both MongoDB data and other business datasets.
• Better performance for BI queries and joins: Analytical queries run faster and more efficiently as compared to executing them on a transactional NoSQL database. 
• Schema enforcement for analytics workloads: Snowflake’s structured table architecture improves data quality, consistency, and reporting reliability. 
• Combining MongoDB data with other sources inside Snowflake: Snowflake’s capabilities go beyond traditional databases, as it supports MongoDB data joined with SaaS, event, and relational datasets inside Snowflake. 
• Enabling SQL-based machine learning tools and BI tools: Snowflake administrators can use standard SQL to power dashboards, ad hoc analysis, and machine learning workflows thanks to its machine learning abilities. 

Moving data from operational databases to analytics platforms is rarely straightforward. When syncing data from MongoDB to Snowflake, teams must choose between multiple integration approaches. Here are the possible methods, followed by a quick comparison table: 

• Method 1: Third-Party ETL/ELT & Data Pipeline Tools (The Hevo way)
• Method 2: Manual Export + Scripted Load (mongoexport + Python + COPY INTO)
• Method 3: Snowflake External Network Access to Pull MongoDB Data

Criteria	Method 1: Fully managed pipeline (Hevo) Try now!	Method 2: Manual Export + Scripted Load	Method 3: Snowflake External Network Access
Setup time	Minutes to hours	Days to weeks	Days (plus infra approvals)
Schema handling	Automated schema detection & evolution	Manual flattening & remapping	Manual handling of JSON → tables
Incremental sync (CDC)	Built-in, near real-time	Custom scripts required	Custom logic required
Handling nested data	Automated normalization & transformations	Complex, error-prone code	Limited; heavy SQL transformations
Reliability & retries	Automatic retries, fault-tolerant	Manual error handling	Manual monitoring & recovery
Maintenance effort	Low (managed platform)	High (scripts, scheduling, failures)	Medium–high (network and security upkeep)
Scalability	Auto-scales with data volume	Breaks at scale	Scales, but adds operational overhead
Cost efficiency (long term)	Predictable, transparent pricing model	Hidden costs in engineering time	Infrastructure and engineering overhead
Best suited for	No-code, reliable pipelines with built-in observability and transparent pricing	One-time or small experimental loads	Highly controlled, niche setups
Overall suitability	Ideal for production use	Not ideal beyond small use cases	Advanced, but complex to manage

Prerequisites for Transitioning Data from MongoDB to Snowflake

MongoDB (Source)

• MongoDB version 4.0 or later (version 6.0+ recommended for production change stream stability)
• Read access to required databases and collections
• Replica set or Atlas cluster configured if you plan to use CDC via Change Streams
• Collections audited for field consistency, nesting depth, and array structures before migration begins

Snowflake (Destination)

• An active Snowflake account (Enterprise or Business Critical tier recommended for production workloads)
• Target database and schema already created
• Snowflake role with USAGE, CREATE TABLE, INSERT, and COPY INTO privileges confirmed
• Virtual warehouse sized for ingestion workloads (start with Small or Medium, scale as needed)

Note: For Snowflake accounts created after the BCR Bundle 2024_08 release, Snowflake recommends connecting ETL tools through a dedicated service user. New service users must authenticate using key-pair authentication rather than passwords. Run the following to set the user type.

Replace <your_snowflake_user> with your actual Snowflake username. 

sqlALTER USER <your_snowflake_user> SET TYPE = SERVICE;

See the Snowflake documentation for the full key-pair setup steps.

Hevo Data Configuration

• Active Hevo Data account
• MongoDB and Snowflake connectors configured in Hevo
• Ingestion mode selected: Full Load, Incremental, or CDC
• Monitoring and alerting enabled for pipeline health

Data Modeling Decisions

Snowflake compute cost monitoring enabled before running large initial loads

How to Connect MongoDB to Snowflake

Moving data from MongoDB to Snowflake depends upon a host of factors, including data volume, transformation complexity, and freshness requirements. Here are some of the most commonly used approaches, ranging from fully managed pipelines to custom-built integrations.

Method 1: Using Managed Data Pipelines (SaaS) like Hevo Data (Recommended) 

Automated ELT tools extract data from MongoDB and load it into Snowflake with minimal manual work. This is the right approach for production pipelines, teams without dedicated data engineering resources, and anyone who needs ongoing sync rather than a one-time load.

Hevo is a no-code ELT platform built for exactly this. It detects schema changes automatically, retries failed loads without intervention, and gives you full visibility into every pipeline run through unified dashboards and detailed logs.

Step 1: Configure MongoDB as a Source

1. Log into Hevo and create a new pipeline.
2. Select MongoDB as the source connector.
3. Enter your connection details: hostname, port, database name, and credentials.
4. Select the collections you want to sync.
5. Choose your ingestion mode:
   • Full load for a one-time historical pull
   • Incremental for timestamp-based sync
   • CDC for real-time change capture via MongoDB change streams

If your MongoDB instance is Atlas, use the SRV connection string. If it is self-hosted, make sure Hevo’s IP ranges are allowlisted in your firewall rules.

Step 2: Configure Snowflake as a Destination

1. Grant Hevo the necessary permissions: CREATE TABLE, INSERT, and MERGE on the target schema.
2. Select Snowflake as the destination.
3. Enter your Snowflake account URL, warehouse name, database, schema, and role.

Step 3: Configure the Pipeline

1. Turn on monitoring and configure alerts for pipeline failures via Slack or email.
2. Map your MongoDB collections to Snowflake tables, or let Hevo auto-map them.
3. Set your sync frequency: real-time, every 15 minutes, hourly, or on a custom schedule.
4. Enable schema drift handling. When new fields appear in MongoDB, Hevo automatically adds the corresponding columns in Snowflake.

And that’s it! With this you have successfully established a connection between Snowflake and MongoDB using Hevo Data. The tool does everything needed without any manual inputs during the transition. 

Best for:

• Teams that need production-ready pipelines with built-in monitoring
• Recurring or real-time MongoDB to Snowflake sync
• Engineering teams that want to stop managing data movement manually

Limitations:

• Tool-specific schema handling behavior, though well documented
• Ongoing subscription cost
• Less control over low-level pipeline behavior compared to fully custom code

Clarifying note:

This method abstracts Snowflake’s objects, such as stages and file formats, so minimal manual configuration is required.

Method 2: Manual Export + Scripted Load

This method runs on a definite chain of events where data is first exported from MongoDB into the files. Next, these files are transformed and loaded into Snowflake using custom scripts, followed by staging and transfer of data. 

Since the scripts used are custom-made, the method grants complete autonomy. However, in return, it demands extensive engineering efforts. Here’s a step-by-step guide on how it is achieved. 

Step-by-Step Procedure: 

Step 1: Extracting data from MongoDB Collections

MongoDB’s mongoexport utility can be used to create a JSON or CSV export of the data stored in any MongoDB collection.

A few points worth noting while using mongoexport:

• mongoexport should be run directly in the system command line, not from the Mongo shell (the Mongo shell is the command-line tool used to interact with MongoDB).
• The connecting user should have at least the read role on the target database. In absence of which, a permission error occurs.
• mongoexport, by default, uses primary read (direct read operations to the primary member in a replica set) as the read preference when connected to Mongos or a replica set.
• Additionally, note that the default read preference, which is “primary read,” can be overridden using the –readPreference option.

Below is an  example on how to export data from the collection named contact_coln into a CSV file, stored in the location /opt/exports/csv/col_cnts.csv

mongoexport --db users --collection contact_coln --type=csv --fields empl_name,empl_address --out /opt/exports/csv/empl_contacts.csv

• To export in CSV format, specify the column names in the collection For instance, the above example specifies the empl_name and empl_address fields to export.The output would look like this:

empl_name, empl_address
Prasad, 12 B street, Mumbai
Rose, 34544 Mysore

• You can also specify the fields to be exported in a file as a line-separated list of fields to export, with one field per line. In our above example, you can specify the empl_name and empl_address fields in a file called empl_contact_fields.txt:

empl_name,
Empl_address

Then, applying the –fieldFile option, define the fields to export from the file:

mongoexport --db users --collection contact_coln --type=csv --fieldFile empl_contact_fields.txt --out /opt/backups/emplyee_contacts.csv

• Exported CSV files will have field names as a header by default. If you don’t want a header in the output file,–noHeaderLine option is used.

• As in the above example –fields can be used to specify fields to be exported. It can also be used to specify nested fields. Suppose you have post_code field with employee_address field; it can be specified as employee_address.post_code

Incremental Data Extract From MongoDB to Snowflake

• So far, we have discussed how to extract an entire MongoDB collection, but here, we go a step further. Over here, it is also possible to filter out the data while removing it from the collection, by passing a query. This is called incremental data extract and is used by passing an –query or -q while querying.  
• Let’s consider the contacts collection discussed above. Suppose the ‘updated_time’ field in each document stores the last updated or inserted Unix timestamp for that document.

mongoexport -d users -c contact_coln -q '{ updated_time: { $gte: 154856788 } }'  --type=csv --fieldFile employee_contact_fields.txt  --out exportdir/emplyee_contacts.csv

• The above command will extract all records from the collection with updated_time greater than the specified value, 154856788.  You should keep track of the last pulled updated_time separately and use that value while fetching data from MongoDB each time.

Step 2: Optional Data Type Conversions and Data Formatting

Along with application-specific logic applied during data transfer, here are a few things to considerations:

• Snowflake supports many character sets, including UTF-8. Read the complete list of supported encodings here.

• If you have worked with cloud-based data warehousing solutions before, you might have noticed that most lack standard SQL constraints like UNIQUE, PRIMARY KEY, FOREIGN KEY, NOT NULL. However, Snowflake supports most SQL constraints.

• Snowflake data types encompass all basic and semi-structured types, including arrays. It also offers built-in functions for handling semi-structured data. The list below displays Snowflake data types that are compatible with various MongoDB data types.

MongoDB Data Type	Snowflake Data Type
DOUBLE	DOUBLE, DOUBLE PRECISION
STRING	STRING, TEXT
BINARY DATA	BINARY
OBJECTID	STRING, TEXT
BOOLEAN	BOOLEAN
DATE	DATE
NULL	NULL
32-BIT INTEGER	INTEGER
TIMESTAMP	TIMESTAMP
64-BIT INTEGER	INT64
DECIMAL128	DECIMAL

As you can see from the table, Snowflake allows almost all date/time formats. On top of it, one can explicitly specify the format when loading data using the File Format Option. The full list of supported date and time formats can be found here.

Step 3: Staging Data Files

When entering or transferring data into a Snowflake table, first, it is essential for the data to be uploaded in a cloud storage service, such as S3. This step is referred to as staging. Snowflake offers two kinds of stages: internal and external.

A. Internal Stage

For every user and table, Snowflake creates and allocates a staging location. This location is used by default for staging activities and is usually named using a convention mentioned below.

• The user stage is named ‘@~’
• The name of the table stage is the name of the table.
• The user or table stages can’t be altered or dropped.
• It is not possible to set file format options in the default user or table stages.

Named internal stages can be created explicitly using SQL statements. While creating named internal stages file format, and other options are fed into the system. This makes loading data into the table easier and with minimal command options.

Note: It is also possible to create named internal stages. 

SnowSQL (SnowFlakes’ SQL CLI client) allows users to run commands such as DDLs or data loads. Here are a few commands to create a stage:

create or replace stage my_mongodb_stage
copy_options = (on_error='skip_file')
file_format = (type = 'CSV' field_delimiter = '|' skip_header = 2);

The PUT command makes it easier to stage data files in an internal stage. The syntax is relatively simple. One needs to specify the file path and stage name alone.

PUT file://path_to_file/filename internal_stage_name

Next, we can upload a file named emplyee_contacts.csv in the /tmp/mongodb_data/data/ directory to an internal stage named mongodb_stage to see the PUT command in action.

put file:////tmp/mongodb_data/data/emplyee_contacts.csv @mongodb_stage;

The best part? One can configure the setup to maximize data load spread during file upload. This is achieved by configuring multiple threads that work in sync with automatic data file compression module.

B. External Stage

It is not surprising that Snowflake supports both Amazon S3 and Microsoft Azure for external staging locations. If the data is in S3 or Azure, all you need to do is create an external stage to point to it, and the data can be loaded into the table.

IAM credentials are to be specified to create an external stage on S3. If the data in S3 is encrypted, encryption keys should also be given. Here’s how it is done.

create or replace stage mongod_ext_stage url='s3://snowflake/data/mongo/load/files/'
credentials=(aws_key_id='181a233bmnm3c' aws_secret_key='a00bchjd4kkjx5y6z');
encryption=(master_key = 'e00jhjh0jzYfIjka98koiojamtNDwOaO8=');

Data for the external stage can then be uploaded using the respective cloud web interfaces, provided SDKs, or third-party tools.

Step 4: Copying Staged Files to Snowflake Table

COPY INTO is the command used to load data from the stage area into the Snowflake table. Compute resources needed to load the data are supplied by virtual warehouses, and the data loading time will depend on the size of the virtual warehouses

E.g.:

A. To load from a named internal stage

copy into mongodb_internal_table
from @mngodb_stage;

B. To load from the external stage :(Here, only one file is specified)

copy into mongodb_external_stage_table
from @mongodb_ext_stage/tutorials/dataloading/employee_contacts_ext.csv;

C. To copy directly from an external location without creating a stage:

copy into mongodb_table

from s3://mybucket/snow/mongodb/data/files
credentials=(aws_key_id='$AWS_ACCESS_KEY_ID' aws_secret_key='$AWS_SECRET_ACCESS_KEY')

encryption=(master_key = 'eSxX0jzYfIdsdsdsamtnBKOSgPH5r4BDDwOaO8=')

file_format = (format_name = csv_format);

D. The subset of files can be specified using patterns

copy into mongodb_table
from @mongodb_stage
file_format = (type = 'CSV')
pattern='.*/.*/.*[.]csv[.]gz';

Some standard format options used in the COPY command for CSV format :

• COMPRESSION – Compression is used for the input data files.
• RECORD_DELIMITER – The character used as records or line separator
• FIELD_DELIMITER -Character used for separating fields in the input file.
• SKIP_HEADER – Number of header lines to skip while loading data.
• DATE_FORMAT – Used to specify the date format
• TIME_FORMAT – Used to specify the time format

Step 5: Migrating to Snowflake

While discussing data extraction from MongoDB to Snowflake, both full and incremental methods are considered. Here, we will look at how to migrate that data from MongoDB to Snowflake effectively. 

There are three popular methods to update the final table with new data after new data is loaded into the intermediate table: 

1. Update the rows in the final table with values from a temporary table, and insert new rows from the temporary table into the final table.

UPDATE  final_mongodb_table t

SET t.value = s.value
FROM  intermed_mongdb_table in
WHERE t.id = in.id;
INSERT INTO final_mongodb_table (id, value)

SELECT id, value FROM  intermed_mongodb_table WHERE NOT id IN (SELECT id FROM final_mongodb_table);

2. Delete all rows from the final table that are also present in the temporary table. Then insert all rows from the intermediate table to the final table.

DELETE .final_mogodb_table f

WHERE f.id IN (SELECT id from intermed_mongodb_table);

INSERT final_mongodb_table (id, value)

SELECT id, value FROM intermed_mongodb_table;

3. MERGE statement – Both inserts and updates can be carried out simultaneously using a single MERGE statement.  We can use this option to apply changes to the temporary table.

MERGE into final_mongodb_table t1 using tmp_mongodb_table t2 on t1.key = t2.key WHEN matched then update set value = t2.value WHEN not matched then INSERT (key, value) values (t2.key, t2.value);

Best For:

• One-time or infrequent data loads.
• Proof-of-concept pipelines.
• Small and medium datasets with stable schemas.

Limitations:

• Not suitable for near real-time ingestion.
• Requires manual setup and maintenance.
• Lacks native support for incremental updates or CDC.

Clarifying Notes:

Requires Snowflake stages, file formats, and manual table management.

Method 3: Snowflake External Network Access to Pull MongoDB Data

In the following method, administrators use Snowflake’s ability to access external networks and execute custom code. It then pulls data directly from MongoDB and stores it in Snowflake. Here’s how it’s done.

Step-by-Step Procedure:

1. First, enable external network access in Snowflake.
2. Now, configure network rules and security integrations.
3. Use Snowflake-supported runtimes to connect to MongoDB.
4. Fetch data programmatically and write it into Snowflake tables.
5. Finally, schedule and manage execution logic for recurring loads. 

• AWS → Kinesis → S3 → SNS → Snowpipe
• Azure → Blob Storage → Event Grid → Snowpipe

Best for:

• Tight integration with Snowflake-native workflows.
• Highly customized ingestion logic.
• Advanced engineering teams. 

Limitations: 

• Demands advanced Snowflake configurations.
• Higher complexity and operational risk.
• Has limited scalability for large datasets.

Clarifying Note:

Snowflake needs external network access, security integrations, and execution frameworks such as Snowpark.

Factors To Consider Before Migrating Data from MongoDB to Snowflake

When migrating data from MongoDB to Snowflake, there are a slew of factors to consider. Avoiding these factors often leads to performance issues, inefficiencies, or unexpected costs. Here are a few of them to consider. 

Data volume and growth rate: Large or fast-growing collections influence ingestion method, warehouse sizing, and long-term costs. Hence, make sure to consider data volume and data growth rates before migrating. 

Schema variability and document structure: Deeply nested documents or highly dynamic data need upfront decisions on flattening versus JSON in VARIANT columns. Since frequent schema changes may increase downstream transformation efforts, schema variability and document structure become critically important. 

Transformation complexity: Before shifting data from MongoDB to Snowflake, it is critically important to understand how much data cleanup, normalization, or enrichment is needed. Failing to do so may result in additional processing layers or orchestration that function beyond simple ingestion. 

Integration with other data sources: Most often, data stored in MongoDB is joined with SaaS, relational data, or event data. In such cases, it has to be aligned with schemas and keys so that cross-source analytics work fine inside Snowflake’s environment. 

Security, governance, and compliance: Review access controls, encryption needs, and handling of sensitive fields before ingestion. Proper governance upfront avoids compliance risks.

MongoDB to Snowflake Migration Checklist 

A failed migration rarely comes from a bad method choice. It usually comes from skipping preparation steps or rushing past post-load validation. Use this checklist to run a clean migration.

Pre-Migration Checklist 

MongoDB (Source) 

• MongoDB version confirmed as 4.0 or later
• Read access granted to all target databases and collections
• Replica set enabled if using CDC via Change Streams
• Collections audited for field consistency, nesting depth, and array structures
• Unique identifier field confirmed per collection (e.g. _id or a custom key) for deduplication
• Estimated document count and data size documented per collection
• IP whitelisting or network access rules updated for your pipeline tool or Snowflake
• Incremental sync field identified (e.g. updated_at timestamp) for non-CDC approaches

Snowflake (Destination) 

• Target database, schema, and warehouse created
• Role permissions confirmed: USAGE, CREATE TABLE, INSERT, COPY INTO
• Stage configured: internal named stage or external stage (S3, Azure Blob, or GCS)
• Virtual warehouse sized appropriately for the initial load volume
• Cost monitoring enabled before starting large loads

Pipeline and Tool

• Migration method selected based on volume, sync frequency, and team capacity
• Schema mapping strategy decided: flatten nested documents or store as VARIANT
• Alerting configured for pipeline errors or sync gaps
• Test run completed on a sample collection (100 to 1,000 documents) before full load
• Rollback plan documented if the initial load fails midway

Post-Migration Checklist

Data Validation

• Row counts match between MongoDB collections and Snowflake tables
• Spot-check 10 to 20 records across multiple collections for field-level accuracy
• Confirm null values and missing fields are handled as expected and not silently dropped
• Confirm timestamps are preserved correctly and timezone normalization is applied
• Confirm nested documents are either flattened correctly or stored as valid VARIANT JSON
• Confirm no duplicate records exist in Snowflake

Pipeline Health

• Incremental sync running and picking up new documents correctly
• Schema drift tested: add a new field in MongoDB and confirm it appears in Snowflake
• Delete replication confirmed if using CDC (insert a document, then delete it, check Snowflake reflects the delete)
• Retry logic confirmed: interrupt the pipeline intentionally and verify it recovers cleanly

Downstream Impact

• Stakeholders notified that data is live in Snowflake and ready for use
• BI dashboards and reports connecting to Snowflake tables return expected results
• SQL queries validated on newly loaded data for accuracy and performance
• Snowflake compute costs within expected range post-migration

Conclusion

Migrating data from MongoDB to Snowflake is no longer subjective. It has evolved into a strategic movement that allows organizations to get reliable analytics, insights, and scalability without overloading their operational databases. 

Data migration can be approached in multiple ways, but not all methods scale equally while in production. For instance,

• Manual and script-based approaches offer flexibility but come with limited support for schema changes and failure recovery. 
• Meanwhile, managed data pipelines reduce operational complexity by handling ingestion retries and schema validation. 

In such scenarios, Hevo Data provides a practical automation path. Hevo enables simple and reliable data movement between the two infrastructures through its built-in schema handling, automated scaling, and observability capabilities.

Want to know how Hevo can simplify your MongoDB to Snowflake pipelines with automated, reliable data movement? Try the 14-day free trial!

Frequently Asked Questions (FAQs)