n8n to ClickHouse: How to Sync Your Data
Sync n8n execution history into ClickHouse with Airbyte. Why full refresh shapes your sync mode, the async_insert fix, and how records land as typed columns.
Syncing n8n to ClickHouse puts your workflow execution history into a columnar store built for fast aggregation, which is exactly what you want when the question is how often automations fail, which ones run longest, or how run volume is trending across thousands of executions.
There is one constraint that shapes everything else about this pipeline, and it is worth knowing before you build: the n8n source can only do full refresh syncs. That single fact determines your sync mode, your schedule, and how much of the ClickHouse destination's machinery you actually get to use.
n8n to ClickHouse at a glance:
What can you sync from n8n?
One stream: executions. The n8n source reads from the n8n API and exposes the record of workflow runs. Workflow definitions, credentials, users, and tags are not available through this connector.
That narrow scope is the point. Execution records are the operational telemetry of your automation layer, and ClickHouse is a good home for telemetry: it scans large volumes quickly, aggregates cheaply, and will happily answer questions across a year of run history without you thinking about indexes. If you want a failure-rate dashboard by workflow, or p95 duration over time, this is a sensible pairing.
If what you actually want is the data your workflows processed rather than the record of them running, point Airbyte at the underlying system instead. This pipeline will not get you there.
Why does full refresh shape the whole design?
The n8n source supports full refresh only. Every sync pulls every available execution record from scratch, with no cursor and no incremental mode. Three consequences follow.
Overwrite is the mode you want. Pairing a full-refresh source with append writes the entire execution history again on every run, so the table grows by its own size each sync. Full refresh overwrite replaces the table instead and leaves you with a clean current snapshot.
ClickHouse deduplication is mostly off the table. The destination handles dedup with the ReplacingMergeTree engine, which needs a primary key and a version to decide which row supersedes which. Those come from incremental sync modes the n8n source cannot offer. You are not losing much, because overwrite gives you correctness a different way, but it does mean the FINAL operator that matters so much when replicating a database into ClickHouse is not part of this setup.
Sync frequency costs real money and load. A busy n8n instance accumulates executions fast, and each run transfers all of them again. Hourly syncing on a high-volume instance means repeatedly moving history that has not changed. Daily, or a few times a day, is usually the right cadence.
One more thing worth saying plainly: the n8n source carries a low sync success rate in Airbyte's own connector metadata. Build monitoring into this pipeline rather than assuming that no alert means no problem.
How do you set up the pipeline?
Step 1: Create an n8n API key
In n8n, open Settings, then API, and select Create an API key. Configure the source with that key plus your instance host. Self-hosted and cloud instances both work. If your organisation restricts traffic by IP, add the Airbyte Cloud IP addresses to the relevant allow lists.
Step 2: Create a dedicated ClickHouse user
Do not reuse an existing account. The ClickHouse destination docs list the grants it needs: create and manage databases, create, alter, drop and truncate tables, and insert and select data.
One setting causes a failure that is hard to diagnose from the error message. If async_insert is enabled on your instance, disable it for the Airbyte user with ALTER USER airbyte_user SETTINGS async_insert = 0; Leave it on and the connection check fails with a complaint about not inserting the expected rows into the check table, while zero rows are actually written.
Step 3: Configure the destination and run
Enter the hostname without a protocol prefix, the port (8123 for HTTP or 8443 for HTTPS), the database, and your credentials. Enable the JSON option if your ClickHouse version supports it, which matters here more than usual because execution records carry nested structures. SSH tunnelling is available but currently in beta. Create the connection, select the executions stream, choose full refresh overwrite, set a frequency you can justify, and sync.
How do n8n records land in ClickHouse?
Version 2.0.0 of the destination was a full rewrite. Records are written directly into typed columns matching the source schema rather than dumped as JSON blobs into raw tables, so the executions table is queryable without an unpacking step.
The type mappings that matter for this data:
- Timestamps become DateTime64(3), millisecond precision, which is enough to compute execution durations accurately.
- Objects become the native JSON type when that option is enabled, and String otherwise. Enable it.
- Arrays and unions always become String, regardless of the JSON setting. Parse them with ClickHouse JSON functions when you need structured access.
- Decimals become Decimal(38, 9), which is far more precision than execution metadata requires.
The practical takeaway is that the parts of an execution record you are most likely to want, such as status, workflow identifier, and start and stop times, land as clean typed columns, while the deeper payload arrives as JSON you query on demand.
Frequently asked questions
Can I sync n8n workflows rather than executions?
No. The connector exposes a single executions stream. Workflow definitions, credentials, and users are not available. A custom connector built against the n8n API is the route if you need them.
Which sync mode should I use?
Full refresh overwrite. The source cannot do incremental, so append would rewrite the entire execution history on every run and leave you with compounding duplicates. Overwrite replaces the table each sync and keeps the snapshot clean.
Do I need the FINAL operator in my queries?
Not for this pipeline. FINAL matters when ReplacingMergeTree is deduplicating rows behind the scenes, which happens with incremental dedup sync modes. Because the n8n source is full refresh only, you are not using those modes and a plain SELECT returns what you expect.
Why does my connection check fail with a check table error?
Almost always async_insert. Disable it for the Airbyte user and the check passes. The error message points at rows not arriving in the check table, which does not obviously suggest an insert-mode setting.
How often should this sync run?
Daily suits most cases. Because every run re-reads the full execution history, frequent syncing multiplies transfer and load for data that has not changed. Match the cadence to how fresh your dashboards actually need to be.
Get your n8n data into ClickHouse
Pick overwrite, disable async_insert, enable the JSON type, and this is a short build with a clear payoff for automation analytics. Sending n8n execution data to an application database instead? See our guide to n8n to Convex. Replicating a production database into the same warehouse? See PostgreSQL to ClickHouse.
Connector behaviour described here reflects the n8n source v0.2.x and the ClickHouse destination v2.x, verified August 2026. Check the linked documentation for current versions.
Integrate with 600+ apps using Airbyte
Move data from 600+ sources into warehouses, lakes, and beyond. Set up pipelines in minutes with pre-built connectors and the Connector Builder.