n8n Data Tables: The Built-In Workflow Table

n8n Data Tables replace an external database in many cases. Here's how to use them correctly and recognize their limitations.

Data Tables are the built-in capability in n8n to store data directly in an instance and reuse it in workflows without connecting an external database. For caching, duplicate detection, or small lookup tables, this is often sufficient, but as data volume grows, the function hits documented limits. As of: August 2026.

What are Data Tables intended for?

According to n8n documentation, Data Tables are used to store, manage, and work with data directly in workflows. Typical use cases include persisting data across multiple workflows, preventing duplicates through marking, reusing prompts in AI workflows, managing generated data, and linking data from various sources. According to documentation, coordinators of the respective project have access to project-based Data Tables.

How do you access Data Tables from a workflow?

For actual management from a workflow, there is the Data Table Node: it supports inserting, retrieving, updating, deleting, and upserting rows, as well as checking whether a row already exists. At the table level, you can also create, list, update, and delete tables. Alternatively, tables can be maintained manually via the Data Tables tab in the project overview; both approaches access the same data management.

Where are the limits?

The documentation specifies a standard limit of 200 MiB for all Data Tables on an instance combined; a warning appears at 80 percent capacity. No concrete upper limit for the number of rows is documented. In the n8n community, this shared limit is regularly discussed, including as a feature request for separate, project-specific size limits instead of a single value per instance. Another recurring discussion point concerns query options, which are deliberately kept simpler in Data Tables than in a full-fledged database.

When should an external database be used?

The documentation itself describes Data Tables as suitable for light to moderate data storage, not for very large data volumes. This assessment aligns with reports from the community: in a much-discussed forum thread, handling more than 600,000 rows is discussed and explicitly recommends switching to an external database like Postgres once volume and query complexity exceed a certain threshold. For a sound decision, the pure number of rows matters less than the question of whether complex queries, indexes, or relationships between tables are needed, because Data Tables are not designed for that.

Data Tables or classic spreadsheet tools?

Compared to Google Sheets or Excel as a data source, Data Tables have the advantage of not requiring external integration and being free from API limits of third-party platforms because they are part of the n8n instance itself. Compared to a real database, they lack functions like complex indexing or transaction security across multiple tables. For getting started with data-driven automation, Data Tables are therefore a good starting point, but switching to an external database should be planned from the beginning as a possible next step once the project grows.

Frequently Asked Questions about n8n Data Tables

How much data fits in n8n Data Tables?

The documentation specifies a shared limit of 200 MiB for all Data Tables on an instance; warnings appear at 80 percent capacity. A fixed upper limit for the number of rows is not documented, but in practice, performance losses are already reported well before reaching the storage limit.

Do I need the Data Table Node or is the Data Tables tab enough?

Both access the same tables. The Data Tables tab in the project overview is suitable for manual maintenance, the Data Table Node for automated management of rows and tables directly from a workflow.

Do Data Tables replace an external database?

For light to moderate data volumes yes, for large volumes or complex queries with relationships between multiple tables no. The documentation explicitly recommends Data Tables not for very large data volumes; in such cases, an external database like Postgres is the more robust choice.

What happens when the storage limit is reached?

According to documentation, n8n displays a warning at 80 percent capacity. Details about behavior at full capacity are not documented at this point; affected teams should therefore respond to the warning early rather than pushing the limit.

Simon Glowik, founder of NordFlux
About the author

Founder of NordFlux. Spent four years automating processes at enterprise scale at Dräger, and now brings that depth to the mid-market — pragmatic and with full data sovereignty.

Certifications

  • Microsoft certified — PL-900 and AZ-900
  • UiPath certified — Automation Developer Associate
  • UiPath zertifiziert — Automation Developer Associate
All articles
Free initial analysis

Concrete questions about automation or AI?

In a free initial analysis we discuss your case directly. No strings attached.