bem vindo à comunidade n8n @Tomasz_Traczyk
de acordo com o discobot aqui da comunidade, não há um limite prático rígido definido para N8N_DATA_TABLES_MAX_SIZE_BYTE, pois o limite real depende da capacidade de armazenamento e desempenho do seu banco de dados Postgres e da memória disponível no servidor. O valor padrão é 50 MB, mas em setups auto-hospedados com Postgres, é viável aumentar para vários GBs se a infraestrutura suportar, conforme discutido em questões da comunidade.
Recomenda-se monitorar o uso de disco e memória, pois tabelas muito grandes podem impactar a velocidade de consultas e o tempo de execução de workflows. Ajuste gradualmente e teste a estabilidade do sistema.
Tecnicamente, você pode aumentar o limite para vários gigabytes porque seu banco de dados Postgres consegue lidar com essa quantidade de dados sem problemas. Porém, só porque o banco de dados consegue armazenar não significa que o n8n consiga exibir. O recurso “Data Tables” integrado foi projetado para pequenas a médias quantidades de informações, não para conjuntos de dados massivos.
O problema real é seu navegador web. Se você armazenar gigabytes de dados nessas tabelas, o editor n8n provavelmente ficará muito lento, travará ou até crasheará quando você tentar abrir ou editar a tabela. Você também pode encontrar erros de “timeout” onde a página falha ao carregar porque está tentando processar uma quantidade muito grande de informações ao mesmo tempo.
Se você realmente precisar armazenar vários gigabytes de dados, a melhor solução é criar uma tabela padrão diretamente no seu banco de dados Postgres e usar o “Postgres Node” para gerenciá-la. Isso mantém o trabalho pesado dentro do banco de dados e longe do seu navegador, garantindo que sua instância n8n permaneça rápida e estável conforme seus dados crescem.
Não acho que essa preocupação seja válida. As APIs de tabelas de dados são paginadas, então mesmo uma tabela grande não deveria exercer muita pressão no navegador.
Além disso, o que estou perguntando é sobre o limite global. Um limite global alto e um grande volume total de dados não implicam automaticamente em tamanhos grandes de tabelas individuais.
Gostaria de manter a segregação de acesso no lado da aplicação entre projetos, e usar a interface CRUD que Data Tables fornece nativamente no n8n.
O nó Postgres não me oferece nenhum dos dois; por isso queria explorar as limitações práticas de Data Tables, e ver se alguém tem experiência executando-as em grande escala, ou se consigo obter algumas recomendações oficiais dos mantenedores.
Aumentar o limite de armazenamento para vários gigabytes é perfeitamente viável e seguro para sua configuração. Como você precisa da interface de usuário integrada e da capacidade de manter dados separados por projeto, continuar usando as Data Tables do n8n é a escolha certa. Seu banco de dados Postgres foi projetado para lidar com esse volume de dados sem nenhum problema.
Sim, vários GB é viável em Postgres auto-hospedado. O padrão de 50MB é apenas um guardrail de camada de aplicação, os dados ficam no Postgres, que não tem problema com esse volume. É bem escalável.
Algumas considerações práticas:
O limite controla o armazenamento total em todas as tabelas de dados da instância, não por tabela. Quando você atinge 80% do limite, o n8n mostra um aviso. Em 100%, as operações de escrita começam a falhar nos workflows. Então defina um valor maior que o seu uso esperado real com algum buffer.
Para aumentá-lo, adicione essa variável de ambiente à sua configuração do n8n:
N8N_DATA_TABLES_MAX_SIZE_BYTES=2147483648
São 2GB. Ajuste conforme suas necessidades.
Quanto ao desempenho, isso é mais importante que o limite de tamanho. As tabelas de dados do n8n usam Postgres por baixo dos panos, mas o n8n gerencia sua própria camada de queries. Para inserts simples e buscas por chave, vários GB funcionam bem na prática. Se você estiver fazendo algo que se pareça com busca, filtro ou agregação em muitos dados em um workflow, você vai sentir. O n8n não otimiza essas queries da forma que uma tabela Postgres devidamente indexada faria. Para alguns GB de dados de referência que você lê principalmente, provavelmente fica bem. Para algo que seja pesado em escrita ou pesado em queries complexas nessa escala, eu manteria os dados em uma tabela Postgres própria e faria queries diretamente com o nó Postgres.
Basicamente, defina o limite, monitore o aviso na interface, e observe o desempenho das queries nos seus workflows conforme os dados crescem. Para vários GB de dados principalmente leitura você provavelmente ficará bem.
Vários GBs é completamente viável com Postgres, o padrão de 50 MB é apenas um limite de segurança para evitar acidentes, não um reflexo do que o banco de dados realmente pode lidar.
Com uma configuração Postgres auto-hospedada, uma abordagem razoável é definir o limite em torno de 25% do espaço em disco disponível no volume do Postgres. Então, se você tem um volume de dados de 40 GB, algo como 10 GB (10737418240 em bytes) é um teto seguro.
Na prática, 2–5 GB cobre a maioria dos casos de uso auto-hospedados pesados. Se você estiver armazenando grandes conjuntos de dados ou fazendo registro de alto volume em tabelas, você pode chegar a 10 GB+, mas nesse ponto vale a pena verificar o desempenho de consultas do Postgres conforme as tabelas crescem, grandes varreduras de tabelas não indexadas diminuirão a velocidade antes que o espaço em disco se torne o problema.
Uma coisa que vale a pena monitorar depois que você aumentar o limite: use SELECT pg_size_pretty(pg_total_relation_size('n8n_data_table')) no Postgres para acompanhar o crescimento real ao longo do tempo. Isso lhe diz se você definiu o teto alto o suficiente ou se está se aproximando dele mais rápido do que o esperado.
A resposta curta: sim, vários GBs é fine. Defina para o que faz sentido para seu disco, depois observe o crescimento real.
Não há um limite rígido no próprio n8n, o limite prático é seus recursos de Postgres e servidor, então alguns GB são viáveis, mas o número é menos importante do que como você usa as tabelas.
A verdadeira restrição é o desempenho das queries, não o tamanho bruto. Tabelas de dados funcionam bem como armazenamento de chave-valor ou consulta em escala de GB no Postgres, mas se um workflow lê grandes pedaços de uma tabela de múltiplos GB na memória a cada execução, você vai enfrentar problemas de RAM e latência muito antes de atingir um limite de armazenamento. Então aumente o limite para corresponder ao seu disco (alguns GB são razoáveis em um VPS decente), mas projete as leituras para extrair apenas as linhas que você precisa, indexadas, em vez de varrer a tabela inteira por execução.
Se você está empurrando para múltiplos GB de dados operacionais, isso geralmente é um sinal de que os dados querem sua própria tabela Postgres que você consulta diretamente com o nó Postgres, em vez de tabelas de dados do n8n, que são destinadas a estados de workflow mais leves. O que você está armazenando lá é o que decide se aumentar o limite ou mover os dados é a opção melhor.