How to store workflow data in n8n?

In n8n you don’t really “store workflow data” inside the workflow itself. Instead, you persist data using something outside the workflow: a database, a storage node, static data, or an external system. n8n only keeps data in memory while the workflow runs, unless you explicitly save it somewhere.

 

What n8n Offers for Storing Data

 

Below are the real and reliable ways to store workflow data in production, from simplest to most robust.

• Static Data (for small config-like values)
• Workflow Data Node (store & read small pieces of data inside n8n)
• Databases (Postgres, MySQL, SQLite, Supabase, etc.)
• External storage services (Google Sheets, Airtable, Notion, S3, Redis, etc.)
• Binary Data storage (for files)

 

1. Static Data (Small Internal Storage)

 

This is built-in storage that exists inside the workflow. It is good for small values you need between runs (like counters, timestamps, config). It is not good for large or frequently changing data.

Two types exist:

• Static Data – shared across all runs
• Global Static Data – shared across workflows (only via API; requires manual enabling)

How to write in a Function node:

// Save a value to workflow static data
const staticData = this.getWorkflowStaticData('global'); // or 'node'
staticData.lastRunValue = 42;

return items;

Read value later:

const staticData = this.getWorkflowStaticData('global');
return [{ json: { value: staticData.lastRunValue }}];

Good for: counters, last-processed ID, small flags.

Not for: records, logs, user data, anything large or structured.

 

2. Workflow Data Node

 

This is n8n’s built-in key–value store that belongs to the workflow. It’s persistent and simpler than dealing with databases. But it is still meant for small to medium data, not entire datasets.

Use cases:

• storing last successful sync time
• storing tokens, flags, or mappings
• keeping a queue index or pointer

Example of writing a key:

return [
  {
    json: {
      key: 'lastProcessedId',
      value: 1234
    }
  }
];

Then the Workflow Data node saves it. Another Workflow Data node can read it later.

 

3. Databases (Production‑grade storage)

 

For anything beyond "small config", always use a real external system. This is what actual production workflows do.

You can use:

• PostgreSQL
• MySQL
• SQLite
• Supabase
• PlanetScale

n8n has nodes for these. Insert, update, select — all handled with queries.

Example query in a PostgreSQL node:

INSERT INTO events (workflow_id, payload)
VALUES ({{$json.id}}, {{$json | jsonStringify}});

This is the most reliable way to store workflow data long-term.

 

4. External Services (Easy, no database admin)

 

If you don’t want to run a database, you can store workflow data in:

• Google Sheets
• Airtable
• Notion
• S3 or DigitalOcean Spaces
• Firestore or DynamoDB

These are great for:

• light analytics
• logging
• lookup tables
• no‑SQL style documents

Example with Google Sheets: append data for logging.

// Pass an object to Google Sheets Append
return [
  {
    json: {
      timestamp: new Date().toISOString(),
      email: $json.email,
      status: 'processed'
    }
  }
];

 

5. Binary Data for Files

 

If the workflow needs to store files (PDFs, images), n8n stores them as binary data connected to an execution. For long-term, push them to external storage like S3.

 

How to Choose the Right Storage

 

• If it’s small config data → static data or workflow data node.
• If it’s user data, logs, row‑based data → use a real database (best).
• If you want convenience with no database → Google Sheets, Airtable, Notion.
• If it’s files → binary data + external storage like S3.

 

Practical Production Advice

 

• Don’t rely on static data for anything large — it’s not built for it.
• Use databases for any workflow that grows over time.
• For high-volume logs, push to external storage (S3, Supabase, Postgres).
• Keep your workflow small; store the heavy stuff outside.
• Use a dedicated “Write to DB” node so you can retry on failure.

 

In real production, the cleanest and safest path is: workflow runs → writes into database → continues processing. n8n executes the orchestration, while the persistent state lives externally.