n8n Data Tables: Native Table Support in n8n Explained

n8n dropped a major update with native data table support — a feature the community had been asking for. Data tables in n8n give you a structured, spreadsheet-like way to store, query, and manipulate tabular data directly inside your workflows without needing an external database or spreadsheet tool to hold state between executions.

In this guide we break down exactly what n8n data tables are, how they work, what operations you can perform on them, and where they fit into your automation stack.

What Are n8n Data Tables?

Data tables are a built-in persistent storage mechanism in n8n that let you store rows and columns of data that survive across workflow executions. Think of them as lightweight in-platform databases — you can create a table with named columns, insert rows, query specific records, update existing data, and delete rows, all from within your workflow using dedicated nodes.

Before data tables existed, workflows that needed to maintain state between runs had to rely on external tools — Google Sheets, Airtable, a PostgreSQL database, or a third-party key-value store. Data tables eliminate that dependency for many common use cases, keeping everything inside n8n and simplifying the overall architecture.

Creating a Data Table

You can create a data table directly from the n8n interface under the Data section in the left sidebar. Click Add Table, give it a name, and define your columns — specifying a name and data type (string, number, boolean, date, or JSON) for each. You can also create tables programmatically using the n8n Data Store node inside a workflow, making it possible to set up tables as part of an automated initialization workflow.

Once created, your table is available across all workflows in your n8n instance. Any workflow can read from or write to any table — there’s no need to pass data between workflows through external services just to share state.

The n8n Data Store Node

The n8n Data Store node is the primary way to interact with data tables inside a workflow. It supports five core operations: Insert a new row, Update an existing row by ID or matching criteria, Upsert (insert if not found, update if found), Get specific rows by ID or filter, and Delete rows. These operations cover the full CRUD cycle, making data tables a fully functional mini-database accessible without any SQL or external credentials.

When inserting, you map workflow data fields to table columns. When querying, you can filter by column values using simple equality checks or more complex conditions. The node outputs matched rows as standard n8n items, so all downstream nodes work with them exactly as they would with data from any other source.

Reading and Filtering Table Data

To read data from a table, use the Data Store node with the Get Many or Get operation. Get Many retrieves all rows or a filtered subset — you can add filter conditions to match rows where a column equals a specific value, contains a string, is greater than a number, or other comparisons. Get retrieves a single row by its unique ID.

Combined with other nodes, this becomes powerful quickly. For example, you can check if a record already exists before deciding whether to insert or update it, retrieve a user’s history to personalize a message, or pull a list of pending items to process in a loop. Because the output is standard n8n items, you can filter, sort, and transform the results with the same nodes you’d use for any other data.

Use Cases for n8n Data Tables

Data tables shine in scenarios where you need lightweight persistence without the overhead of setting up an external database. Some of the most common use cases include: deduplication — storing processed record IDs so you never process the same item twice across executions; rate limiting — tracking how many times a user has triggered a workflow within a time window; queue management — maintaining a list of items to process and marking them complete as workflows run; and caching — storing API responses or computed values to avoid redundant calls on subsequent runs.

They’re also great for simple configuration storage — keeping dynamic settings like feature flags, API endpoints, or threshold values that you want to change without editing the workflow itself. And for AI agent workflows, data tables work well as a persistent memory layer where the agent can store and retrieve facts across conversations.

Data Tables vs. External Databases

Data tables are not a replacement for a full-featured database — they don’t support complex joins, indexes for performance on large datasets, advanced query languages, or multi-user access control beyond what n8n provides. For workflows processing thousands of records or requiring sub-millisecond query times, a dedicated database like PostgreSQL or MySQL remains the right choice.

Where data tables win is simplicity and speed of setup. There’s no connection string to configure, no cloud database to provision, no schema migrations to manage. For small-to-medium datasets — say, under a few thousand rows — and for use cases where the data is primarily consumed within n8n workflows, data tables are faster to implement and easier to maintain than an external database integration.

Tips for Working with Data Tables

A few best practices to keep in mind. First, design your table schema thoughtfully upfront — adding columns later is possible but renaming them can break existing workflows that reference the old name. Second, use the Upsert operation whenever you’re unsure whether a record already exists — it handles both insert and update in a single node, eliminating the need for an IF node to check first. Third, for deduplication workflows, store a unique identifier from the source system (like an order ID or email address) as the lookup key rather than relying on n8n’s auto-generated row ID. Finally, periodically clean up tables used as queues or caches — rows accumulate over time and can slow down queries on large tables if not pruned.