n8n to MongoDB: How to Move Your Data
Move n8n into MongoDB with Airbyte. Why a document store suits execution payloads, and what happens when a workflow moves something large.
Moving n8n into MongoDB keeps a record of workflow runs in a shape that matches what they actually are. Execution records carry whatever moved through the workflow, which is nested and irregular, and a document store is the destination least bothered by that.
This guide covers the managed path with Airbyte. Two things shape the build: this pairing suits the data better than most, and a workflow handling large objects can produce records that test a limit nobody thinks about.
n8n to MongoDB at a glance:
Why move data from n8n to MongoDB?
Two situations account for most of these pipelines.
The first is keeping execution history intact rather than trimmed. n8n prunes its own records and the payloads are the interesting part when something went wrong, so a store that keeps them whole is worth more than one that flattens them.
The second is serving a tool that looks up runs by identifier. If your questions are counts and trends across months of automation activity, n8n to BigQuery answers those far better than a document store will.
What do you need before you start?
Four things, and the last two depend on what your workflows actually carry:
An n8n API key and your instance host. Created under Settings and then API in n8n. Because instances are frequently self-hosted, a failed connection test is usually networking rather than credentials. The n8n source documentation covers the fields.
Realistic expectations about the stream. Executions is the only one, so workflow definitions, credentials, users and tags are not available and reporting will show identifiers rather than names.
A sense of what your heaviest workflow moves. Execution payloads contain the data that passed between nodes, so a workflow handling large files or wide API responses produces correspondingly large records.
Monitoring on the connection itself. This is a Marketplace connector carrying a low sync success rate in Airbyte's own metadata, so a quiet pipeline is not evidence of a healthy one.
If your instance or database restricts traffic by IP, add the Airbyte Cloud IP addresses to the relevant allow lists before you begin.
How do you build an n8n to MongoDB pipeline in Airbyte?
Step 1: Look at your largest execution record
Open a run from your heaviest workflow in n8n and see how much data it carried, because that is the shape of what this pipeline will store. Most automation runs produce small records; a workflow moving documents, images or large API responses produces something quite different, and knowing which you have changes what you need to think about.
Step 2: Configure the n8n source
Click Sources in the left navigation, then New Source, and select n8n, following adding a source. Supply the API key and host. Airbyte tests the connection immediately, and a self-hosted instance behind a private network is the usual reason that test fails.
Step 3: Configure the MongoDB destination
Click Destinations, then New Destination, and select MongoDB, following adding a destination. Supply the connection string, database and credentials. Documents arrive carrying metadata fields the destination adds alongside the execution itself.
Step 4: Create the connection and index by execution
Click Connections, then New connection, select the executions stream and a sync mode. Only full refresh is available, so every run re-reads everything. Then create an index on the n8n execution identifier, since that is how anything will look a run up.
Keep a mapping of workflow identifiers to names somewhere, because the connector will not give you one.
Why does a document store suit this better?
Because an execution record is a document, not a row. It describes a workflow run and carries the data that passed between its nodes, which means the interesting part is nested, irregular and different for every workflow you have built.
In most destinations that is the awkward part. A warehouse stores those payloads as text or a semi-structured column and somebody writes path expressions to reach inside; a strictly typed database needs the shape decided in advance, which is impossible when each workflow produces its own. Here the record simply stores as what it is.
That makes this a better fit than the volume suggests, and it is worth being clear about what you gain. Looking up why a particular run failed and reading what it was carrying is pleasant here and tedious elsewhere. Counting failures per workflow per week is the reverse, which is why the aggregation questions belong in a warehouse and this collection should serve lookups.
What happens to a very large execution?
It tests a ceiling most people never meet. MongoDB caps the size of a single document, which is generous for ordinary records and finite all the same, and an execution record contains whatever the workflow moved rather than a summary of it.
So a workflow that fetches a large file, pulls a wide API response or passes a sizeable object between nodes can produce an execution record far bigger than the automation that produced it would suggest. Most workflows never approach the limit; the one that does is usually the one somebody built to move data around, and it will not be obvious from the outside which that is.
Check your heaviest workflow before assuming this is fine, and if you have one that carries large payloads, consider whether its execution history belongs here at all. The same characteristic affects performance in other destinations too, so this is not a MongoDB weakness so much as a property of the data that this destination happens to make explicit.
Frequently asked questions
Can I sync workflow definitions as well?
No. The connector exposes the executions stream only, so you will see workflow identifiers rather than names unless you maintain a mapping yourself.
Why does every sync take the same time?
The source supports full refresh only, so each run re-reads every execution from the API regardless of how few are new.
Could a record be too large to store?
Possibly, if a workflow moves large objects between nodes, since MongoDB caps individual document size. Check your heaviest workflow rather than assuming.
The connection test fails.
Usually networking rather than credentials, since n8n is often self-hosted behind a private network. Check reachability before regenerating the key.
Can I do this without writing code?
The pipeline, yes. The index on the execution identifier and the workflow name mapping are yours, and both make the collection usable.
Get your n8n data into MongoDB
Look at your heaviest workflow first, because execution records carry whatever moved between nodes and a document store has a size ceiling that ordinary runs never approach. Expect one stream and identifiers rather than names. Then index by execution identifier and keep this collection for looking runs up, sending the counting questions to a warehouse where they belong.
Airbyte's connector catalog includes 600+ pre-built connectors, so automation history can outlive the tool that produced it. For the same source into a relational database, see n8n to PostgreSQL, and for the same source into a search engine, n8n to Elasticsearch.
Integrate with 700+ apps using Airbyte
Move data from 700+ sources into warehouses, lakes, and beyond. Set up pipelines in minutes with pre-built connectors and the Connector Builder.