According to the discobot here in the community, there is no hard practical limit defined for N8N_DATA_TABLES_MAX_SIZE_BYTE, as the real limit depends on the storage capacity and performance of your Postgres database and the available memory on the server. The default value is 50 MB, but in self-hosted setups with Postgres, it is viable to increase it to several GBs if the infrastructure supports it, as discussed in community questions.
It is recommended to monitor disk and memory usage, as very large tables can impact query speed and workflow execution time. Adjust gradually and test system stability.
Technically, you can increase the limit to several gigabytes because your Postgres database can handle that amount of data without any trouble. However, just because the database can store it doesn’t mean n8n can display it. The built-in “Data Tables” feature is designed for small to medium amounts of information, not for massive datasets.
The real problem is your web browser. If you store gigabytes of data in these tables, the n8n editor will likely become very slow, freeze, or even crash when you try to open or edit the table. You may also run into “timeout” errors where the page fails to load because it is trying to process too much information at once.
If you truly need to store several gigabytes of data, the best solution is to create a standard table directly in your Postgres database and use the “Postgres Node” to manage it. This keeps the heavy lifting inside the database and away from your browser, ensuring your n8n instance remains fast and stable as your data grows.
I don’t think this concern is valid. The data tables APIs are paginated, so even a big table should not put a lot of pressure on the browser.
On top of that, what I am asking about is the global limit. A high global limit and a large total volume of data do not automatically imply large individual table sizes.
I’d like to keep the application-side access segregation between projects, and use the CRUD UI within n8n that Data Tables provides out of the box.
The Postgres node gives me neither; that’s why I wanted to explore the practical limitations of Data Tables, and see if anyone has experience running them at scale, or if I can get some official recommendations from the maintainers.
Increasing the storage limit to several gigabytes is perfectly feasible and safe for your setup. Since you need the built-in user interface and the ability to keep data separated by project, continuing to use n8n’s Data Tables is the right choice. Your Postgres database is designed to handle this volume of data without any issues.
Technically, n8n doesn’t “stress” the system to check the global limit. It simply asks Postgres for the total disk space used by the tables, which is a nearly instant operation regardless of how much data you have. Additionally, because the interface loads data in small pages (pagination), having a massive amount of total data won’t slow down your browser or crash the application.
The only real risk is not the total size of your tables, but the size of a single entry. While the list of rows is paginated, the content of a single cell is not. If a workflow accidentally saves a massive amount of text (like a huge HTML page or a giant JSON file) into one cell, the browser may freeze or crash when you try to open that specific row.
To keep everything running smoothly, go ahead and increase the limit to your desired size. Just make sure your workflows don’t save excessively large blobs of text in single cells. If you notice the system slowing down during high-traffic periods, you can simply increase the database connection pool size in your settings to handle more simultaneous requests.
Yes, several GB is feasible on self-hosted Postgres. The 50MB default is just an application-layer guardrail, the data lives in Postgres, which has no issue with that volume. It is quite scalable.
A few practical considerations:
The limit actually controls the total storage across all data tables in the instance, not per table. When you hit 80% of the limit, n8n shows a warning. At 100%, write operations start failing in workflows. So set it higher than your actual expected usage with some buffer.
To increase it, add this env var to your n8n configuration:
N8N_DATA_TABLES_MAX_SIZE_BYTES=2147483648
That’s 2GB. Adjust to match your needs.
Regarding performance, this is more important than the size limit. n8n’s data tables use Postgres under the hood but n8n manages its own query layer. For simple inserts and key lookups, several GB is fine in practice. If you’re doing anything resembling a search, filter, or aggregation over large data in a workflow, you’ll feel it. n8n isn’t optimizing those queries the way a properly indexed Postgres table would. For a few GB of reference data you’re mostly reading, probably fine. For anything write-heavy or complex-query-heavy at that scale, I’d keep the data in a proper Postgres table and query it directly with the Postgres node.
Basically, set the limit, monitor the warning in the UI, and watch the query performance in your workflows as the data grows. For several GB of mostly-read data you’ll likely be fine.
Several GBs is completely feasible with Postgres, the 50 MB default is just a safety cap to prevent accidents, not a reflection of what the database can actually handle.
With a self-hosted Postgres setup, a reasonable approach is to set the limit to around 25% of your available disk space on the Postgres volume. So if you have a 40 GB data volume, something like 10 GB (10737418240 in bytes) is a safe ceiling.
In practice, 2–5 GB covers most heavy self-hosted use cases. If you’re storing large datasets or doing high-volume logging into tables, you might push toward 10 GB+, but at that point it’s worth checking Postgres query performance as the tables grow, large unindexed table scans will slow things down before disk space becomes the issue.
One thing worth monitoring once you raise the limit: use SELECT pg_size_pretty(pg_total_relation_size('n8n_data_table')) in Postgres to track actual growth over time. That tells you whether you’ve set the ceiling high enough or if you’re approaching it faster than expected.
The short answer: yes, several GBs is fine. Set it to what makes sense for your disk, then watch the actual growth.
There is no hard ceiling in n8n itself, the practical limit is your Postgres and server resources, so several GB is feasible but the number is less important than how you use the tables.
The real constraint is query performance, not raw size. Data tables are fine as a key-value or lookup store at GB scale on Postgres, but if a workflow reads large chunks of a multi-GB table into memory on every execution, you will hit RAM and latency problems long before you hit a storage limit. So raise the limit to match your disk (several GB is reasonable on a decent VPS), but design reads to pull only the rows you need, indexed, rather than scanning the whole table per run.
If you are pushing into multiple GB of operational data, that is usually a sign the data wants its own Postgres table you query directly with the Postgres node, rather than n8n data tables, which are meant for lighter workflow state. What are you storing in there, that decides whether raising the cap or moving the data is the better call.