n8n to MySQL: How to Move Your Data
Move n8n into MySQL with Airbyte. Why full refresh overwrite deletes the history you wanted, what one stream leaves out, and how to build a real archive.
Moving n8n into MySQL gives you a durable record of what your automations actually did. n8n shows recent executions in its own interface, but most instances prune that history to keep the database manageable, so the record of a workflow that failed quietly three months ago is usually gone by the time anybody asks about it.
This guide covers the managed path with Airbyte. Two things shape the build: there is exactly one stream and it is full refresh only, which turns the sync mode into a decision about whether this table mirrors n8n or outlives it.
n8n to MySQL at a glance:
Why move data from n8n to MySQL?
Two situations account for most of these pipelines.
The first is keeping history the source will not keep. Execution records answer questions that arrive weeks late: how often this workflow fails, whether it has been getting slower, when the failures started. n8n prunes to protect its own database, and a copy elsewhere is the only way those questions stay answerable.
The second is putting execution state where an application can read it, such as an internal status page or a monitoring view that sits beside other operational tables you already keep in MySQL. The limit is volume. A busy instance produces a lot of executions, guidance for this destination is around ten gigabytes, and if you intend to keep years of history for analysis rather than months for operations, n8n to BigQuery is the better home.
What do you need before you start?
Four things, and the second is the one that determines whether this pipeline is worth building:
An n8n API key and your instance URL. Generated from within n8n, and pointed at your own instance whether that is cloud or self-hosted. The n8n source documentation covers the configuration, which is mercifully short.
Your instance's pruning settings. Find out whether executions are pruned, after how long, and whether successful runs are discarded sooner than failures. This number is the window the pipeline has to work in, and if it is short then your sync schedule has to be shorter.
A MySQL database and a decision about what the table means. Mirror or archive, and it is a real decision rather than a default. Make it before the first sync, because the two are configured differently and converting one into the other afterwards means going back for data that no longer exists.
Somewhere to notice failures. This is a Marketplace connector with a modest sync success rate, which is worth knowing rather than discovering. A failed sync during a pruning window is the one case where data is genuinely lost, so alert on sync failures rather than checking occasionally.
If your database or n8n instance restricts traffic by IP, add the Airbyte Cloud IP addresses to the allow list before you begin.
How do you build an n8n to MySQL pipeline in Airbyte?
Step 1: Find out what your instance prunes, and how often
Everything else follows from this. If executions are kept for a fortnight, a weekly sync is comfortable and a monthly one loses half of them permanently. If they are kept for two days, the pipeline needs to run several times a day and a failed sync becomes an incident rather than an inconvenience. Ask whoever administers the instance rather than assuming defaults, because pruning is usually tuned to whatever the n8n database could stand.
Step 2: Configure the n8n source
Click Sources in the left navigation, then New Source, and select n8n, following adding a source. Supply the host and API key. There is one stream to select, so this is the shortest source configuration you will do all week, and correspondingly little can go wrong with it.
Step 3: Configure the MySQL destination
Click Destinations, then New Destination, and select MySQL, following adding a destination. Supply the host, port, database and credentials. The destination adds metadata columns of its own, and execution records nest, so check the generated column names against MySQL's 64-character identifier limit once the first sync has run.
Step 4: Create the connection and choose mirror or archive
Click Connections, then New connection, select the stream and a sync mode. Only full refresh is available, and the variant you pick is the whole design. Overwrite replaces the table with whatever n8n currently holds. Append adds each run's results to what is already there, keeping records the source has since deleted at the cost of duplicates you deduplicate yourself.
Set the schedule against the pruning window rather than against anything else, and index the execution identifier straight away, since every query you write against this table will use it.
Why is there only one stream?
Because the connector exposes executions and nothing else. No workflow definitions, no credentials, no users, no tags. That is a narrow surface, and it is worth knowing before you promise anybody a complete picture of their automation estate, because this is a record of runs rather than of what was running.
The practical gap is naming. An execution refers to its workflow by identifier, and the thing that maps identifiers to human names is not in this pipeline, so a table of failures tells you that something broke four hundred times without saying what. Most teams solve this with a small reference table they maintain by hand or populate from the n8n API separately, then join to it.
The deeper gap is that workflows change and this data does not record that. An execution from March ran against whatever the workflow looked like in March, and nothing here captures that version, so a sudden change in failure rate might be a broken integration or might be somebody editing a node. Keeping your workflow definitions in version control alongside this table is the honest way to close that, and it sits outside the pipeline.
Should your MySQL table mirror n8n or outlive it?
Answer that before the first sync, because full refresh overwrite makes the table a mirror. Each run replaces its contents with whatever n8n currently holds, which means anything the instance has pruned since the last sync is deleted from your copy too. A mirror is a perfectly reasonable thing to build if you want current state for a status page, and a poor one if anybody believes it is an archive.
Full refresh append makes it an archive instead. Every sync adds the full current set of executions to what is already stored, so records survive in MySQL long after n8n has forgotten them. The cost is duplication: an execution present across ten syncs arrives ten times, and the table grows by the whole visible window each run rather than by what is new.
So an archive needs two things from you in MySQL. A view that deduplicates on the execution identifier, keeping one row per execution, which is what everybody should query rather than the raw table. And a watch on growth, because ten gigabytes is the rough guidance for this destination and an append-only table fed several times a day reaches it faster than people expect. Prune your own copy on your own terms, keeping failures longer than successes if that suits, which is the whole point of holding the data somewhere you control.
Frequently asked questions
Can I sync workflow definitions as well?
Not through this connector, which carries executions only. Workflow definitions, credentials, users and tags are all outside its scope, so keep definitions in version control if you need to know what ran.
Why can I not use incremental sync?
The connector offers full refresh only. Choosing between overwrite and append is how you decide whether the destination tracks the source or accumulates beyond it.
Will my copy keep executions that n8n has deleted?
Only with append. Overwrite replaces the table each run, so pruned executions disappear from your copy at the next sync as if they had never been there.
How closely should I watch this pipeline?
More closely than most. It is a Marketplace connector with a modest success rate, and a run of failures spanning your instance's pruning window loses data permanently. Alert on failure rather than reviewing periodically.
Can I do this without writing code?
The pipeline, yes, and it is a short setup. An archive also wants a deduplicating view and a retention job of your own, which is modest SQL but not nothing.
Get your n8n data into MySQL
Start with the pruning window, because it sets the schedule and decides how much a failed sync costs. Then choose deliberately between a mirror and an archive, since full refresh overwrite will quietly delete the history you built this pipeline to keep. If you choose the archive, add a deduplicating view on the execution identifier, watch the table's growth against MySQL's comfortable range, and alert on sync failures rather than trusting a connector whose success rate is only fair.
Airbyte's connector catalog includes 600+ pre-built connectors, so automation history can outlive the tool that produced it. For the same source into another operational database, see n8n to PostgreSQL, and for comparable run history into the same destination, Jenkins to MySQL.
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.