N8N_DATA_TABLES_MAX_SIZE_BYTES es el límite para el tamaño total de todas las tablas de datos en una instancia de n8n. El valor por defecto es 50 MB.
Me gustaría obtener una recomendación sobre cuánto es viable aumentarlo en un entorno autohospedado con una base de datos Postgres. ¿Es viable varios GB?
¿Cuál es el mensaje de error (si existe)?
no aplica - pidiendo una recomendación de configuración
Por favor comparte tu flujo de trabajo
no aplica - pidiendo una recomendación de configuración
Comparte el resultado devuelto por el último nodo
no aplica - pidiendo una recomendación de configuración
bienvenido a la comunidad n8n @Tomasz_Traczyk
de acuerdo con el discobot de la comunidad, no hay un límite práctico rígido definido para N8N_DATA_TABLES_MAX_SIZE_BYTE, ya que el límite real depende de la capacidad de almacenamiento y rendimiento de tu base de datos Postgres y de la memoria disponible en el servidor. El valor predeterminado es 50 MB, pero en configuraciones autohospedadas con Postgres, es viable aumentar a varios GB si la infraestructura lo soporta, conforme se discutió en problemas de la comunidad.
Se recomienda monitorear el uso de disco y memoria, ya que tablas muy grandes pueden impactar la velocidad de consultas y el tiempo de ejecución de flujos de trabajo. Ajusta gradualmente y prueba la estabilidad del sistema.
Técnicamente, puedes aumentar el límite a varios gigabytes porque tu base de datos Postgres puede manejar esa cantidad de datos sin ningún problema. Sin embargo, solo porque la base de datos pueda almacenarlo no significa que n8n pueda mostrarlo. La función integrada «Data Tables» está diseñada para cantidades pequeñas o medianas de información, no para conjuntos de datos masivos.
El problema real es tu navegador web. Si almacenas gigabytes de datos en estas tablas, el editor de n8n probablemente se volverá muy lento, se congelará o incluso se bloqueará cuando intentes abrir o editar la tabla. También podrías encontrarte con errores de «timeout» donde la página no carga porque está intentando procesar demasiada información a la vez.
Si realmente necesitas almacenar varios gigabytes de datos, la mejor solución es crear una tabla estándar directamente en tu base de datos Postgres y usar el «Postgres Node» para gestionarla. Esto mantiene el trabajo pesado dentro de la base de datos y lejos de tu navegador, asegurando que tu instancia de n8n se mantenga rápida y estable a medida que tus datos crecen.
No creo que esta preocupación sea válida. Las APIs de las tablas de datos tienen paginación, por lo que incluso una tabla grande no debería ejercer mucha presión en el navegador.
Además, lo que estoy preguntando es sobre el límite global. Un límite global alto y un gran volumen total de datos no implican automáticamente tamaños de tabla individuales grandes.
Me gustaría mantener la segregación de acceso del lado de la aplicación entre proyectos y usar la interfaz de usuario CRUD dentro de n8n que proporciona Data Tables de forma predeterminada.
El nodo Postgres no me ofrece ninguno de los dos; por eso quería explorar las limitaciones prácticas de Data Tables y ver si alguien tiene experiencia ejecutándolas a escala, o si puedo obtener algunas recomendaciones oficiales de los mantenedores.
Aumentar el límite de almacenamiento a varios gigabytes es perfectamente viable y seguro para tu configuración. Como necesitas la interfaz de usuario integrada y la capacidad de mantener los datos separados por proyecto, seguir utilizando las Tablas de Datos de n8n es la opción correcta. Tu base de datos Postgres está diseñada para manejar este volumen de datos sin ningún problema.
Técnicamente, n8n no “sobrecarga” el sistema para verificar el límite global. Simplemente le pide a Postgres el espacio total en disco utilizado por las tablas, que es una operación casi instantánea sin importar cuántos datos tengas. Además, como la interfaz carga los datos en pequeñas páginas (paginación), tener una cantidad masiva de datos totales no ralentizará tu navegador ni bloqueará la aplicación.
El único riesgo real no es el tamaño total de tus tablas, sino el tamaño de una entrada individual. Aunque la lista de filas está paginada, el contenido de una sola celda no lo está. Si un flujo de trabajo guarda accidentalmente una cantidad masiva de texto (como una página HTML enorme o un archivo JSON gigante) en una celda, el navegador puede congelarse o bloquearse cuando intentes abrir esa fila específica.
Para mantener todo funcionando sin problemas, adelante y aumenta el límite al tamaño que desees. Solo asegúrate de que tus flujos de trabajo no guarden cantidades excesivamente grandes de texto en celdas individuales. Si notas que el sistema se ralentiza durante períodos de alto tráfico, puedes simplemente aumentar el tamaño del grupo de conexiones de la base de datos en tu configuración para manejar más solicitudes simultáneas.
Sí, varios GB es viable en Postgres autohospedado. El límite predeterminado de 50 MB es solo una barrera a nivel de aplicación; los datos viven en Postgres, que no tiene problema con ese volumen. Es bastante escalable.
Algunas consideraciones prácticas:
El límite en realidad controla el almacenamiento total en todas las tablas de datos de la instancia, no por tabla. Cuando alcanzas el 80% del límite, n8n muestra una advertencia. Al 100%, las operaciones de escritura comienzan a fallar en los flujos de trabajo. Así que establécelo más alto que tu uso esperado real con algún margen.
Para aumentarlo, añade esta variable de entorno a tu configuración de n8n:
N8N_DATA_TABLES_MAX_SIZE_BYTES=2147483648
Eso son 2 GB. Ajusta según tus necesidades.
Regardante el rendimiento, esto es más importante que el límite de tamaño. Las tablas de datos de n8n usan Postgres bajo el capó, pero n8n gestiona su propia capa de consultas. Para inserciones simples y búsquedas por clave, varios GB están bien en la práctica. Si haces algo parecido a una búsqueda, filtro o agregación en datos grandes en un flujo de trabajo, lo sentirás. n8n no está optimizando esas consultas como lo haría una tabla Postgres debidamente indexada. Para algunos GB de datos de referencia que principalmente estás leyendo, probablemente esté bien. Para cualquier cosa que sea pesada en escritura o pesada en consultas complejas a esa escala, mantendría los datos en una tabla Postgres adecuada y los consultaría directamente con el nodo Postgres.
Básicamente, establece el límite, monitorea la advertencia en la UI y observa el rendimiento de las consultas en tus flujos de trabajo mientras crecen los datos. Para varios GB de datos principalmente de lectura, probablemente estarás bien.
Varios GB es completamente viable con Postgres, el límite predeterminado de 50 MB es solo un tope de seguridad para prevenir accidentes, no un reflejo de lo que la base de datos realmente puede manejar.
Con una configuración autohospedada de Postgres, un enfoque razonable es establecer el límite alrededor del 25% del espacio en disco disponible en el volumen de Postgres. Así que si tienes un volumen de datos de 40 GB, algo como 10 GB (10737418240 en bytes) es un tope seguro.
En la práctica, 2-5 GB cubre la mayoría de casos de uso autohospedados pesados. Si estás almacenando conjuntos de datos grandes o realizando registro de alto volumen en tablas, podrías llegar a 10 GB+, pero en ese punto vale la pena verificar el rendimiento de las consultas de Postgres a medida que las tablas crecen, los escaneos de tablas grandes sin indexar ralentizarán las cosas antes de que el espacio en disco se convierta en el problema.
Una cosa que vale la pena monitorear una vez que aumentas el límite: usa SELECT pg_size_pretty(pg_total_relation_size('n8n_data_table')) en Postgres para rastrear el crecimiento real a lo largo del tiempo. Esto te indica si has establecido el tope lo suficientemente alto o si te estás acercando a él más rápido de lo esperado.
La respuesta corta: sí, varios GB está bien. Establécelo a lo que tenga sentido para tu disco, luego observa el crecimiento real.
No hay un límite máximo fijo en n8n mismo, el límite práctico depende de tus recursos de Postgres y servidor, así que varios GB es viable pero el número es menos importante que cómo uses las tablas.
La verdadera restricción es el rendimiento de las consultas, no el tamaño bruto. Las tablas de datos funcionan bien como almacén clave-valor o búsqueda a escala de GB en Postgres, pero si un flujo de trabajo lee grandes fragmentos de una tabla de varios GB en memoria en cada ejecución, te encontrarás con problemas de RAM y latencia mucho antes de alcanzar un límite de almacenamiento. Así que aumenta el límite para que coincida con tu disco (varios GB es razonable en un VPS decente), pero diseña las lecturas para extraer solo las filas que necesitas, indexadas, en lugar de escanear toda la tabla en cada ejecución.
Si estás utilizando varios GB de datos operacionales, eso normalmente es una señal de que los datos necesitan su propia tabla Postgres que consultes directamente con el nodo Postgres, en lugar de las tablas de datos de n8n, que están pensadas para un estado de flujo de trabajo más ligero. Lo que estés almacenando allí es lo que decide si aumentar el límite o mover los datos es la mejor opción.