n8n to PostgreSQL: How to Move Your Data

Moving n8n into PostgreSQL gives you a queryable record of how your automations have actually behaved. Which workflows fail most, whether reliability is drifting, how long runs take now compared with three months ago. The n8n interface shows recent executions; a database lets you ask questions across all of them.

This guide covers the managed path with Airbyte. Two characteristics shape the whole design: the connector exposes a single stream, executions, and it supports full refresh only. That combination turns your sync mode into the decision that defines what this pipeline is actually for.

n8n to PostgreSQL at a glance:

Why move data from n8n to PostgreSQL?

Two situations account for most of these pipelines, and Postgres suits both better than a warehouse would.

The first is reliability analysis at a modest scale. Execution records are small, the questions are simple aggregations, and a Postgres instance you already run is cheaper and simpler than provisioning warehouse capacity for a few hundred thousand rows. Airbyte recommends Postgres destinations for volumes of roughly 10GB or less, and n8n execution history sits comfortably inside that.

The second is feeding an internal tool. An operations dashboard or a status page that already reads Postgres can query this data directly, without anyone building a warehouse connection for it. If your automation estate is large enough that execution history runs to gigabytes, a warehouse becomes the better destination.

What do you need before you start?

Short list, and one item is an expectation rather than a credential:

An n8n API key and your instance host. Create the key under Settings and then API in n8n. Because n8n is frequently self-hosted, the host is whatever address your instance answers on rather than a fixed vendor domain, and a failed connection test here is usually networking rather than credentials.

Realistic expectations about the stream. The connector exposes executions, the record of workflow runs. Workflow definitions, credentials, users and tags are not available, so you get the runs but not the catalogue of what was run.

Monitoring on the connection itself. This is a Marketplace connector carrying a low sync success rate in Airbyte's own metadata. Build alerting on sync failures rather than assuming silence means success.

A Postgres user with write permission. On the target schema. If you already run a Postgres destination on an older connector version, read the migration guide before upgrading, because downstream models referencing raw tables will need updating.

Finally, find out how long your n8n instance keeps execution records before pruning them. That number determines how often this pipeline needs to run, and it is the single most useful thing to know before configuring anything.

How do you build an n8n to PostgreSQL pipeline in Airbyte?

Step 1: Check your n8n retention settings

n8n instances are commonly configured to prune execution history so the database does not grow without limit. Find out what that window is, because it tells you both how much history your first sync will capture and how often you need to run. If executions are pruned after seven days and you sync fortnightly, you are losing half of them permanently.

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 if your n8n instance sits inside a private network you may need to allow inbound traffic from wherever Airbyte runs.

Step 3: Configure the PostgreSQL destination

Click Destinations, then New Destination, and select Postgres, following adding a destination. From version 3.0.0 the Postgres destination uses Direct Load architecture, writing records straight to final tables with no intermediate raw tables, and adds its own metadata columns including a JSONB column recording per-row typing changes.

Step 4: Choose append or overwrite deliberately

Click Connections, then New connection, and choose a sync mode. This defines what the pipeline is. Full refresh overwrite gives you a mirror of what n8n currently holds, which is simple and loses everything n8n has pruned. Full refresh append accumulates, so your database outlives n8n's retention and becomes the archive.

Append needs one thing handled: because every sync re-reads all retained executions, the same execution arrives repeatedly while it remains in n8n. Deduplicate on the execution identifier in a downstream view, keeping the most recent extraction of each. That is a few lines of SQL and it is what makes append usable at all.

Are you building a mirror or an archive?

Worth answering explicitly, because the two designs diverge immediately and converting between them later is not free.

A mirror is the simpler build. Overwrite on every sync, no duplicates, no deduplication view, and a table that always matches what n8n shows. It suits a dashboard about current reliability and is completely useless for the question about how things looked six months ago, because six months ago has been pruned from both systems.

An archive is more valuable and asks slightly more of you: append mode, a deduplication view, and the discipline of syncing more often than n8n prunes. In exchange your database accumulates a permanent record of automation reliability that nothing else in your stack holds. If anyone has asked for trends rather than status, you want the archive, and you want it configured before the history you care about is deleted.

How do you model a single stream usefully?

With only executions available and no workflow definitions, your records reference workflows by identifier and nothing tells you what those workflows are called. A dashboard of failure counts by workflow ID is technically correct and practically useless to the people who need to read it.

The pragmatic fix is a small mapping table in Postgres, maintained by hand or by a lightweight job, translating workflow identifiers to names and owning teams. It feels unsatisfying to maintain manually, it takes minutes, and it turns the dataset from a technical artefact into something a team lead will actually look at.

Beyond that the modelling is ordinary. Derive duration from start and end timestamps, flag failures, aggregate by workflow and by day. Because Postgres is likely already serving whatever reads this, put those aggregations in views rather than in each consuming application, so the definitions live in one place.

Frequently asked questions

Can I sync workflow definitions as well as executions?

No. The connector exposes the executions stream only. Workflow definitions, credentials, users and tags are not available, so maintain a mapping table if you need workflow names.

Can I sync incrementally from n8n?

No. The source supports full refresh only, so every sync re-reads the retained execution history. Use append plus a deduplication view if you want to accumulate history.

Why is my database missing older executions?

Either you are using overwrite mode, which mirrors whatever n8n currently holds, or n8n pruned them between syncs. Switch to append and sync more often than your retention window.

Is PostgreSQL big enough for this data?

For most instances, comfortably. Airbyte recommends Postgres destinations for roughly 10GB or less, and execution records are small. A very large automation estate on append mode is where you would reconsider.

Can I do this without writing code?

The Airbyte setup is entirely UI-driven. If you choose append mode you will want a deduplication view in SQL, which is short and worth having.

Get your n8n data into PostgreSQL

Check the retention setting first, decide whether you are building a mirror or an archive, and sync more often than n8n prunes. Add a deduplication view if you chose append, a mapping table so workflows have names, and alerting on the connection because this connector's success rate warrants it.

Airbyte's connector catalog includes 600+ pre-built connectors, so automation reliability data can sit alongside everything else you analyse. For the same source into a warehouse, see n8n to BigQuery, and for the same source feeding a streaming platform, n8n to Kafka.

Start syncing now →