n8n to DynamoDB: How to Move Your Data
Move n8n execution history into DynamoDB with Airbyte. Why the JSON shape blocks indexing, designing the access pattern first, and safe full refreshes.
Moving n8n into DynamoDB puts workflow execution history where an application can look it up by key. A status page showing whether a customer's integration ran, or an internal tool surfacing recent executions for a given workflow, is the kind of thing this pairing serves.
One honest word before you build. DynamoDB is a key-value store, and this connector offers a single stream with full refresh only, so the combination is narrow. If you want to analyse automation reliability rather than serve it to software, a database or warehouse is the better destination.
n8n to DynamoDB at a glance:
Why move data from n8n to DynamoDB?
One situation fits this pairing, and it is worth confirming you are in it before building.
It fits serving an application at scale. If your product needs to show whether an automation ran for a particular customer, and it needs to answer that on every page load for a lot of customers, DynamoDB does key-based lookups at that volume without a connection pool to manage.
It does not fit reliability analysis. Failure rates, duration trends and which workflows break most are aggregate questions, and DynamoDB is a poor place to ask them. The n8n to PostgreSQL guide covers a destination suited to that, and is the more common need.
What do you need before you start?
Two credentials and two decisions that shape what the table can ever do:
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, and a failed connection test is usually networking rather than credentials.
AWS credentials, or better, an IAM role. With write access to the target table. On self-managed Airbyte running in AWS, a role attached to the workload avoids long-lived keys in the configuration.
A decision about your key design. DynamoDB items are addressed by a partition key and optionally a sort key, and those are what your application looks up by. Work out that access pattern before creating the table, because it is not something you change later.
Your n8n retention setting. n8n instances commonly prune execution history so the database does not grow without limit. That number tells you how much history your first sync captures and how often the pipeline needs to run.
Note also that this is a Marketplace connector carrying a low sync success rate in Airbyte's own metadata, so build alerting on sync failures rather than assuming silence means success.
How do you build an n8n to DynamoDB pipeline in Airbyte?
Step 1: Design the access pattern first
Write down exactly how your application will fetch items, then design the partition and sort keys to serve it. Looking up recent executions for a workflow suggests the workflow identifier as partition key and the start time as sort key, which gives you that query directly.
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. If your n8n instance sits inside a private network you may need to allow inbound traffic from wherever Airbyte runs.
Step 3: Configure the DynamoDB destination
Click Destinations, then New Destination, and select DynamoDB, following adding a destination. Supply the region, table name prefix and credentials. Execution volumes are modest, so write capacity is less likely to be a problem here than on a database replication pipeline, though it is still worth checking before the first load.
Step 4: Handle the full refresh carefully
Click Connections, then New connection, and choose a sync mode. Only full refresh is available, and overwrite is destructive, so an application reading during a sync sees an incomplete table. Load into a new table, verify it, then repoint the application by changing the table name it reads.
Set the frequency against your n8n retention rather than how fresh anyone wants the page, and stay comfortably inside it, because executions pruned before a sync reads them are gone from both systems.
Why do your fields not become attributes?
Because the destination writes each record as a JSON document rather than mapping fields onto DynamoDB attributes individually. An execution record with a status, a start time and a workflow reference does not become an item with three attributes, it becomes an item holding one structure containing all of them.
The consequence is indexing. A global secondary index is built on an attribute, and a field buried inside a JSON document is not an attribute, so you cannot create one on execution status. If your application needs to find all failed executions rather than all executions for a workflow, that requirement has to be met by the key design.
This is why the access pattern comes first. On most destinations you can model your way out of a surprise after loading; here the shape of what lands constrains what the table can ever do, and on a single-stream source there is no second dataset to compensate with.
What does full refresh only mean in practice?
That every sync re-reads everything n8n still holds and writes it all again. On a small instance that is unremarkable. Against a live application table it is the thing to design around, because overwrite empties the table before repopulating it.
The load-then-repoint pattern solves that cleanly. Write to a new table, confirm the row count looks right, then change the table name your application reads. Your users never see a partial table, and the previous version stays available if you need to roll back.
It also means this table mirrors n8n rather than outliving it. Anything n8n has pruned is absent, and a full refresh will not bring it back, so if somebody wants execution history going back a year, that is a different pipeline into a destination where append mode accumulates snapshots.
Frequently asked questions
Is DynamoDB a good destination for n8n data?
For serving an application by key-based lookup at scale, yes. For reliability analysis and aggregation, a relational database or warehouse is considerably better suited.
Can I build an index on execution status?
No. Records land as a JSON document rather than individual attributes, and a global secondary index needs an attribute. Satisfy the access pattern through your key design instead.
Can I sync incrementally from n8n?
No. The source supports full refresh only, so every sync re-reads the retained execution history and writes it again.
Is overwrite safe against a live table?
No. It is destructive, so an application reading during a sync sees an incomplete table. Load into a new table and repoint the application once it is verified.
Can I do this without writing code?
The Airbyte setup is entirely UI-driven. Your application code will need to read the JSON structure rather than individual attributes, which is worth knowing before anyone builds against it.
Get your n8n data into DynamoDB
Confirm this is an application pipeline rather than an analytics one, then settle the access pattern before the first sync because the JSON shape means you cannot index your way out of it afterwards. Use the load-then-repoint pattern for every refresh, sync inside your n8n retention window, and alert on failures.
Airbyte's connector catalog includes 600+ pre-built connectors, so automation data can reach an application and an analytical store at once. For the analysis version, see n8n to PostgreSQL, and for the same destination fed by a database, PostgreSQL to DynamoDB.
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.