N8N_DATA_TABLES_MAX_SIZE_BYTES 是 n8n 實例中所有資料表的總大小限制。預設值為 50 MB。
我想要建議在具有 Postgres 資料庫的自託管環境中增加多少是可行的。幾 GB 是否可行？
不適用 - 詢問配置建議
不適用 - 詢問配置建議
不適用 - 詢問配置建議
歡迎加入 n8n 社群 @Tomasz_Traczyk
根據我們社群的 discobot，N8N_DATA_TABLES_MAX_SIZE_BYTE 沒有嚴格的實際限制，因為實際限制取決於您的 Postgres 資料庫的儲存容量和效能，以及伺服器上可用的記憶體。預設值為 50 MB，但在使用 Postgres 的自託管設置中，如果基礎設施支援，可以提升到數個 GB，詳見社群討論。
建議監測磁碟使用量和記憶體，因為表格過大可能會影響查詢速度和工作流程執行時間。請逐步調整並測試系統的穩定性。
技術上來說，你可以將限制增加到幾個 GB，因為你的 Postgres 資料庫完全能夠處理這樣的數據量。然而，資料庫能儲存數據並不代表 n8n 能夠顯示它。內建的「資料表」功能是為了處理小到中等量的資訊，而不是大規模的資料集。
真正的問題在於你的網頁瀏覽器。如果你在這些表格中儲存了幾個 GB 的數據，當你試著打開或編輯表格時，n8n 編輯器很可能會變得非常緩慢、卡頓，甚至崩潰。你也可能遇到「逾時」錯誤，頁面因為需要一次處理過多資訊而無法載入。
如果你真的需要儲存幾個 GB 的數據，最好的解決方案是直接在你的 Postgres 資料庫中建立標準表格，並使用「Postgres Node」來管理它。這樣做可以讓繁重的工作保留在資料庫內，遠離你的瀏覽器，確保你的 n8n 實例在數據增長時保持快速穩定。
Hi @kjooleng，感謝你的回應。
我認為這個顧慮是不成立的。資料表API是分頁的，所以即使是一個大型表格也不應該對瀏覽器造成太大的壓力。
除此之外，我所詢問的是全域限制。較高的全域限制和較大的資料總量不會自動意味著個別表格的大小較大。
我想要在應用程式端保持專案之間的存取隔離，並使用n8n中Data Tables提供的CRUD UI。
Postgres節點都不能提供這些功能；這就是為什麼我想要探索Data Tables的實際限制，看看是否有人有大規模運行它們的經驗，或者我是否能從維護者那裡獲得一些官方建議。
將儲存限制增加到幾個 GB 對於您的設定來說完全可行且安全。由於您需要內建使用者介面和按專案分離資料的能力，繼續使用 n8n 的資料表是正確的選擇。您的 Postgres 資料庫設計用來處理這個資料量，完全沒有問題。
從技術上講，n8n 不會「壓力測試」系統來檢查全域限制。它只是向 Postgres 詢問表所使用的總磁碟空間，無論您有多少資料，這都是一個幾乎瞬間完成的操作。此外，由於介面以小頁面的方式載入資料（分頁），即使您有大量的總資料量，也不會減慢您的瀏覽器速度或使應用程式當機。
唯一真正的風險不是您的表的總大小，而是單個條目的大小。雖然列表是分頁的，但單個儲存格的內容不是。如果工作流程意外地將大量文字（例如巨大的 HTML 頁面或龐大的 JSON 檔案）保存到一個儲存格中，當您嘗試打開該特定列時，瀏覽器可能會凍結或當機。
為了保持一切順利運作，請繼續並將限制增加到您所需的大小。只需確保您的工作流程不會將過度大量的文字內容保存在單個儲存格中。如果您在高流量期間注意到系統速度變慢，您可以簡單地增加設定中的資料庫連線池大小，以處理更多同時發生的請求。
Hi @Tomasz_Traczyk,
是的,自託管 Postgres 上可以處理幾 GB 的資料。50MB 預設值只是應用層的保護機制,資料存儲在 Postgres 中,該系統可以輕鬆處理這個資料量。它的可擴展性相當不錯。
幾個實務考量:
這個限制實際上控制的是實例中所有資料表的總儲存空間,而不是單個表。當你達到限制的 80% 時,n8n 會顯示警告。達到 100% 時,工作流程中的寫入操作會開始失敗。所以應該將限制設定為高於你的實際預期使用量,並留有緩衝空間。
要增加限制,請將此環境變數新增到你的 n8n 設定中:
N8N_DATA_TABLES_MAX_SIZE_BYTES=2147483648
這是 2GB。根據你的需求進行調整。
關於效能,這比大小限制更重要。n8n 的資料表在後台使用 Postgres,但 n8n 管理自己的查詢層。對於簡單的插入和鍵值查閱,在實務上幾 GB 是沒問題的。如果你在工作流程中對大量資料進行任何類似搜尋、篩選或聚合的操作,你會感受到效能的影響。n8n 的查詢最佳化方式不如一個適當索引的 Postgres 表。對於幾 GB 的參考資料且你主要是進行讀取操作,可能沒問題。但對於大規模寫入或複雜查詢操作,我建議將資料保存在適當的 Postgres 表中,並使用 Postgres 節點直接查詢。
基本上,設定限制、監控 UI 中的警告,並在資料增長時觀察工作流程中的查詢效能。對於幾 GB 的主要讀取資料,你可能不會有問題。
用 Postgres 的話，幾 GB 完全是可行的，50 MB 的預設值只是為了防止意外而設置的安全上限，並不反映資料庫實際能處理的容量。
對於自主託管的 Postgres 設定，合理的做法是將限制設為 Postgres 磁碟區上可用磁碟空間的約 25%。例如，如果您有 40 GB 的資料磁碟區，設定為 10 GB（以位元組計為 10737418240）是安全的上限。
實際上，2～5 GB 涵蓋大多數高強度的自主託管使用情況。如果您要儲存大型資料集或對表執行大量日誌記錄，您可能會朝著 10 GB 或以上發展，但在那個時間點值得檢查 Postgres 查詢效能，因為隨著表格增長，大型未編製索引的表掃描會在磁碟空間成為問題之前減速。
提高限制後值得監控的一件事：在 Postgres 中使用 SELECT pg_size_pretty(pg_total_relation_size('n8n_data_table')) 來追蹤實際成長情況。這會告訴您是否已設定足夠高的上限，或者成長速度是否比預期更快。
簡短的回答：是的，幾 GB 是可以的。根據您的磁碟設定合理的值，然後監控實際成長。
n8n 本身沒有硬上限，實際限制取決於你的 Postgres 和伺服器資源，所以數 GB 是可行的，但具體數字不如你如何使用這些表來得重要。
真正的限制是查詢效能，而非原始資料量。資料表作為 Postgres 上的鍵值或查詢存放區在 GB 級別是沒問題的，但如果工作流在每次執行時都將多 GB 表的大量資料塊讀入記憶體，你會遠在達到儲存限制之前就遇到 RAM 和延遲問題。所以將限制提高到符合你的磁碟容量（在一台不錯的 VPS 上，數 GB 是合理的），但要設計讀取操作使其只拉取需要的行，並建立索引，而不是每次執行都掃描整個表。
如果你正在推送多 GB 的運作資料，這通常表示該資料應該有自己的 Postgres 表，使用 Postgres 節點直接查詢，而不是使用 n8n 資料表，後者用於較輕量的工作流狀態。你儲存什麼資料決定了提高上限還是遷移資料是更好的選擇。