n8n Data Tables vs Postgres: When to Use Each

Stopping a webhook from processing the same event twice?Data Table. This is the single best thing they do, and I'll spend a section on it below.

Storing a marker so a nightly workflow knows where it left off?Data Table. One row, two columns, done. You were about to abuse a Google Sheet for this. Don't.

A lookup or mapping table you edit by hand a few times a year? Data Table. The built-in editor is genuinely nice, and the alternative was a hardcoded object in a Code node that nobody but you can safely change.

Leads, orders, contacts, anything a client will eventually want a dashboard on? Postgres. Every time. The instant a human wants to see the data outside n8n, workflow-private storage becomes a liability, and migrating later is worse than starting right.

An event log, message history, or anything that grows forever? Postgres. The 200 MiB budget is shared across your entire instance, and an append-only table will eat it and then break every other workflow that writes to storage.

It's a real table living inside n8n. You define typed columns, it holds rows, and a Data Table node reads and writes them from any workflow in the same project. No connection string, no second container, no credential to rotate. n8n calls it integrated data storage, which is accurate and undersells how much friction it removes.

Column types are string, number, boolean and date. Types are enforced on write, so pushing a string into a number column fails immediately at the node instead of poisoning three steps downstream — a genuine upgrade over the Google Sheets pattern it replaces, where everything is a string and you find out in the CRM.

The row operations are Insert, Get, Update, Delete, Upsert, If Row Exists and If Row Does Not Exist. Those last two are the interesting ones — they're branching operations, not data operations. They pass the input through on the matching side and let you route on the answer without writing a comparison yourself. Several operations also support a dry run, which is a considerate thing to ship and I've used it more than I expected.

None of these show up in the tutorials, and all four have cost somebody a rebuild.

1. The 200 MiB cap is instance-wide. Not per table, per instance. n8n warns at about 80% and again at 100%, and past the line you can't add rows by hand and executions that insert or update start failing. Do the arithmetic before you commit: at roughly 500 bytes a row that's on the order of 400,000 rows before overhead. Fine for markers and lookups, useless for logs. Self-hosted can raise it with N8N_DATA_TABLES_MAX_SIZE_BYTES. Cloud can't, so on Cloud it's a design constraint, not a setting — one more line in the cloud versus self-hosted ledger.

2. The Code node can't touch them.Direct programmatic access isn't supported, so every read and write is a node on the canvas. For a handful of lookups that's fine and arguably clearer. For a loop that needs to check two hundred ids, you're building a Split In Batches contraption to do what one SQL statement does. That's the signal you've outgrown it.

3. Tables are scoped to a project.A workflow in another project can't reach the table, which is correct behaviour and still surprises people who assumed instance-wide storage. If your automations are split across client projects and they need shared reference data, that's a database.

4. They don't travel with the workflow. This is the one that bites in production. Export a workflow, import it into your prod instance, and you get the nodes but not the table behind them. Nothing in the JSON carries it. If you're moving workflows through git — which you should be, and you can do it without the Enterprise plan — the table is a manual step on the other side, or a bootstrap workflow that creates and seeds it on first run. Write that bootstrap. Future you will not remember the schema.

There's a fifth, smaller one worth naming: no JSON or array column typeat the time of writing. Workflow items are nested objects, so you end up stringifying a payload into a string column and parsing it after the read — and losing the ability to filter on anything inside it. It's the most-requested addition in the community for a reason.

If you build one data table this week, build the idempotency ledger. Two columns: the external event id as a string, and a date. Drop an If Row Exists node right after the webhook trigger, route the match branch to a No Operation, and insert the id on the success path at the end.

That's it. That small table kills the entire class of bug where a provider retries a webhook, or a queue redelivers, or somebody double-clicks, and your workflow cheerfully charges a card twice. Before data tables you solved this with an external Redis or a Postgres table — real infrastructure, for a two-column problem. I've written up the full duplicate-execution pattern separately; the logic doesn't change, the storage just got a lot cheaper to stand up.

One caveat that matters: the ledger grows forever unless you prune it.Add a scheduled workflow that deletes rows older than your provider's retry window — thirty days is generous for most — or you will meet the 200 MiB cap from the least interesting direction possible.

Anything a client will look at. The moment there's a dashboard, an admin screen, or a “can you send me a CSV of last quarter” request, you want SQL and you want a second application able to connect. That's the whole argument behind the Supabase lead database build — n8n writes it, but n8n was never the only reader.

Anything an AI agent needs to search semantically, too. Data tables filter on conditions; they don't do similarity. That's a vector store question, and the answer is usually pgvector on the Postgres you already run.

And conversation memory. It looks like a data table job right up until you count the rows: every turn of every session, forever, in a 200 MiB budget shared with everything else. I compared Postgres and Redis for agent memory and neither answer was “keep it inside n8n.”

Here's the honest framing I use with clients: a data table is a private variable for your automation. A database is a shared recordof the business. Both are correct in their lane, and almost every mess I've been called in to fix came from someone storing a shared record in a private variable because it was faster on the day.