n8n Data Tables: when to skip an external database

One need keeps coming up across n8n workflows: keeping track of state between runs — which emails have already been processed, how many times a user triggered a given webhook today, which documents are still waiting in a queue. Until recently, the answer almost always meant reaching for an external service (Supabase, Airtable, Google Sheets), even for a three-column need. Since version 1.113, n8n ships Data Tables: structured storage built into the instance, with no database to provision. This guide covers what the feature actually does, how to use it, and where its limits kick in.

What n8n Data Tables actually is

Data Tables (still in beta) adds persistent data tables to n8n, with typed columns (text, number, boolean, date, JSON) and rows your workflows can create, read, update, and delete. Unlike a simple key-value store, each table has a schema defined ahead of time in the UI, in a dedicated Data Tables tab reachable from the left-hand menu.

The feature is available on every plan, including self-hosted on the Community Edition — no Enterprise license required. Tables are scoped to a project: only members of that project (or you, for a personal space) can access it, which keeps a test table created for one client from showing up elsewhere.

Concrete use cases

Data Tables targets light storage needs — exactly the kind of problem that usually pushes people to spin up a Supabase project for three columns:

• Deduplication: recording the ID of every item already processed (an email, a ticket, an RSS feed entry) so the same data never gets reprocessed twice between runs — a recurring need in almost every AI email triage workflow or competitive monitoring setup.
• Rate limiting: counting how many times a user or API key has triggered a workflow within a given time window, alongside the practices covered in our 429 errors guide.
• Queue management: keeping a list of items to process and marking them done as runs complete, useful for smoothing out batch processing without a full Redis queue mode setup when volume doesn't justify it.
• Caching: storing the result of an expensive API call (an embedding, a summary, an enrichment lookup) to avoid redoing it on every run — a direct complement to our guide on tracking AI call costs.

The Data Table node: operations and column types

Three ways to interact with a Data Table: the Data Table node on a workflow canvas, the DataTable API endpoint, or the Data Tables tab in the UI for manual inspection. The node exposes the expected operations — insert, retrieve (with filters), update, delete — configurable without writing a query.

Each column is declared with a strict type (text, number, boolean, date, or JSON for more complex structures), which avoids the classic spreadsheet pitfall where a column meant to hold dates ends up mixing text formats and numbers. One thing to know upfront: direct programmatic access from a Code node isn't supported. Any read or write has to go through the Data Table node in the workflow flow; a Code node can process the data afterward, but it can't query the table itself.

Example: deduplicating already-processed emails

In an email triage workflow close to the one in the Inbox AI Pack (€79), a Data Table node placed right after the IMAP trigger can check whether a message's ID already exists in an emails_processed table before kicking off AI classification. If it does, the workflow stops there (via an IF node); if not, it processes the message and then inserts its ID into the table. That guardrail, combined with a properly configured Error Workflow, prevents double processing after a retry following a failure — without needing a whole Supabase project for a single column of IDs.

The limits to know about

Data Tables isn't a database replacement. Three structural limits matter:

• Capped storage: 50MB total per instance by default (adjustable self-hosted via the N8N_DATA_TABLES_MAX_SIZE_BYTES environment variable), with warnings at 80% of quota. Beyond that, inserts and updates fail with execution errors — plenty for a queue or a cache, far too tight for a document store.
• No advanced querying: no complex joins, no performance indexes for large volumes, no elaborate query language. Built for light-to-moderate storage, not tens of thousands of rows queried continuously.
• No direct access from the Code node, as mentioned above — a constraint worth factoring in early if your logic leans heavily on custom JavaScript.

Data Tables vs. Supabase or Postgres: which one to pick

Need	Data Tables	Supabase / Postgres
Deduplication, cache, small queue	✅ Enough, zero external setup	Works, but overkill
High volume, complex queries, joins	❌ Not built for it	✅ Postgres or Supabase node
Vector store for RAG	❌ No vector type	✅ pgvector
Audit trail with long-term retention	⚠️ Watch the 50MB limit	✅ See our GDPR guide, close to the Compliance & Audit Pack (€149)
Access from a Code node	❌ Not supported	✅ Free-form SQL

The practical rule: if the data only exists to run a workflow's internal logic (state, deduplication, short-term cache), Data Tables avoids spinning up a whole external service for a handful of columns. Once the data needs to be queried outside n8n, grows past tens of thousands of rows, or stores vectors, a real database is still the right call.

Why structure beats improvising

The most common alternative to Data Tables, before it shipped, was repurposing a Google Sheet or an Airtable base to act as a mini-database — a widespread practice, but one that inherits the classic blind spots of spreadsheets used as a data system. A well-known study by Panko (What We Know About Spreadsheet Errors, Journal of End User Computing, 1998 — see it on Google Scholar) found that 20 to 40% of spreadsheets in real-world use contain at least one non-trivial error, often due to the lack of strict typing and schema enforcement. A typed table with columns declared upfront, even a minimal one like Data Tables, eliminates a good chunk of that error class by construction — without replacing a full relational database for the needs that genuinely call for one.

Going further

Data Tables fills a real gap between "no persistent state at all" and "spin up a Supabase project for three columns": great for deduplication, caching, or a small queue, best kept to modest volumes while the feature is still in beta. The FlowKit packs rely on Supabase for their heavier-duty needs (email queues, vector stores, audit trails), but nothing stops you from bolting on a local Data Table for a lightweight guardrail — a good way to test the idea before, if volume grows, migrating to a full database.