n8n to Amazon Redshift: How to Move Your Data

Load n8n execution history into Amazon Redshift with Airbyte. Full refresh only, the single executions stream, required S3 staging, and keeping history.

Summarize with AI:

Loading n8n to Amazon Redshift puts your workflow execution history into a warehouse, where you can measure automation reliability over time, find which workflows fail most, and join run data against the business outcomes those workflows drive. Airbyte does it with no code. One characteristic of the source shapes the whole pipeline, and it is worth settling before you schedule anything: the n8n source supports full refresh only.

Every sync reads your entire execution history. In a warehouse that is manageable, because you can overwrite the table rather than accumulate copies, but it makes sync frequency a cost decision.

CapabilitySupportedWhat it means for this pipeline
StreamsOneExecutions only. Workflows and credentials are unavailable
Incremental syncNoFull refresh only, so every run reads all history
S3 stagingRequiredRedshift needs a bucket and IAM credentials
SSH tunnelSQL connection onlyStaging traffic to S3 does not use the tunnel
Connector maturityMarketplaceLow reported sync success, so monitor rather than assume

What the n8n source gives you

The n8n source reads from the n8n API and exposes a single stream: executions, the record of workflow runs. Workflow definitions, credentials, users, and tags are not available through this connector.

That single-stream limitation shapes what your analysis can say. You get run records with identifiers, timings, and status, but not the workflow names and descriptions that would make a dashboard readable. If you want to report on workflow names rather than IDs, you will need to maintain a mapping table yourself, or build a small custom connector against the n8n workflows endpoint using the Connector Builder and sync it alongside.

Setup is short. Create an API key in n8n under Settings, then API, and configure the source with that key plus your instance host. This is a Marketplace connector carrying a low sync success rate in Airbyte's own metadata, so build monitoring in rather than assuming a quiet pipeline is a healthy one.

Because there is no incremental mode, use full refresh overwrite. Append would stack an entire copy of your execution history on every sync, and since the history only grows, so would the duplication. Overwrite gives you a table matching n8n as of the last run, which is a clean contract for anything reading it.

One consequence worth planning for: if n8n prunes old executions, and most instances are configured to, then a full refresh overwrite discards history from your warehouse the moment n8n discards it. If keeping long-term history is the point of this pipeline, sync into a staging table and merge into a permanent one rather than overwriting your reporting table directly.

Setting up Redshift

The Redshift destination requires S3 staging: data is uploaded to a bucket as files with a manifest, then loaded with a COPY command, which is the approach Redshift's own best practices recommend. It is not optional.

Create a staging bucket in the same AWS region as your Redshift cluster, since cross-region transfer costs money and slows every load. Create an IAM user with read and write access to that bucket and generate an access key for it.

If your cluster sits in a private VPC, note a limitation that catches people: S3 staging does not use the SSH tunnel. The tunnel covers the SQL connection only, and staging traffic to S3 is secured through public HTTPS. If your security review assumed all traffic flows through the bastion, raise it before building rather than during an audit.

On permissions, Airbyte writes into two schemas: your target schema and a raw data schema defaulting to airbyte_internal, which can be overridden in advanced settings. Your user needs create permissions on the database and usage plus create on the schema. The one people forget is SELECT on SVV_TABLE_INFO, which the connector queries for table metadata, and whose absence produces a connection that tests fine and then fails mid-sync.

Modelling execution data

n8n execution records carry nested structures describing node-level input, output, and errors, which arrive as JSON rather than flat columns. The metrics most teams want, such as failure rate by workflow, median duration, and time to recovery, all need a model that extracts status, timings, and the workflow identifier into typed columns first.

Remember that Redshift performance depends on sort and distribution keys, which Airbyte does not set for you. On an executions table, sorting on the start timestamp is usually the right choice, since almost every question you ask of this data is bounded by a time window.

Frequently asked questions

Can I sync workflow definitions as well as executions?

Not with this connector, which exposes only the executions stream. Build a custom connector against the n8n workflows endpoint if you need names and definitions.

Can I sync only new executions?

No. The source supports full refresh only, so every sync reads the whole history. Use overwrite rather than append, and set a frequency that reflects the volume.

Will I lose history when n8n prunes old executions?

With a straight overwrite, yes. Sync into a staging table and merge into a permanent table if long-term history matters.

Does the SSH tunnel cover my staging data?

No. It covers the SQL connection only. S3 staging traffic is secured through public HTTPS rather than routed through the bastion.

Get your n8n data into Amazon Redshift

Use full refresh overwrite, merge into a permanent table if you need history beyond n8n's retention, grant SELECT on the metadata view, and sort on the start timestamp. For the same source into other destinations, see our guides to n8n to Databricks and n8n to ClickHouse.

Start syncing now →

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.