SQLite o PostgreSQL: cuándo toca el cambio

Por defecto, n8n arranca con SQLite, una base de datos de archivo sin proceso de servidor propio que no requiere instalación separada. Para instancias de prueba, automatizaciones individuales y el inicio, esto es suficiente. Pero en cuanto ejecute varias ejecuciones de flujo de trabajo simultáneas, utilice el modo cola o quiera operar varias instancias main, n8n recomienda explícitamente PostgreSQL a partir de la versión 13 en su propia documentación. El momento adecuado para el cambio depende menos de un número fijo de usuarios que de tres factores: el número de ejecuciones simultáneas, la arquitectura planificada y con qué frecuencia ya aparecen errores de bloqueo en los registros. Estado: julio de 2026.

Señales de que SQLite está llegando a sus límites

En la comunidad de n8n aparece una y otra vez el mismo patrón de error: SQLITE_BUSY: database is locked. La causa está en el diseño de SQLite, que solo permite un acceso de escritura por archivo a la vez. Si varios workflows se ejecutan en paralelo o abre el editor durante ejecuciones activas, los accesos de escritura al mismo archivo colisionan. A corto plazo, el modo WAL (Write-Ahead Logging) con un tiempo de espera (busy timeout) de al menos 5000 milisegundos ayuda a reducir la frecuencia de errores. Sin embargo, la limitación subyacente de un solo escritor no se ve afectada por ello y regresa de forma fiable cuando aumenta la carga.

Los umbrales que el propio n8n indica

En su documentación, n8n no indica un número fijo de ejecuciones por día como punto de cambio, sino que vincula el límite a decisiones de arquitectura concretas.

• Modo cola planificado: Para el funcionamiento en producción con modo cola, n8n indica directamente que el modo de ejecución queue con una base de datos SQLite no se recomienda. En cuanto varios procesos worker escriben en paralelo en la misma base de datos, se necesita Postgres.
• Varias instancias main (multi-main): Para la alta disponibilidad con varios procesos main, n8n exige explícitamente una conexión a Postgres y Redis; SQLite no está previsto para ello.
• Concurrencia de workers: El valor de concurrencia por worker es 10 por defecto, n8n recomienda al menos 5. Con muchos workers y baja concurrencia, según la documentación existe riesgo de agotar las conexiones a la base de datos, una situación que una base de datos de archivo único sin un verdadero pool de conexiones absorbe estructuralmente mal.
• Valor de referencia del benchmark: En las pruebas de rendimiento oficiales, una instancia única con backend Postgres alcanza hasta 220 ejecuciones de workflow por segundo. No es un límite de SQLite, pero muestra para qué clase de carga está diseñado Postgres en n8n.
• Señal de n8n Cloud: Incluso en su propio producto en la nube, Postgres queda reservado a los planes Enterprise Scaling, todos los niveles inferiores funcionan con SQLite. Esto refleja aproximadamente a partir de cuándo el propio n8n considera necesario el cambio.

Pasos de migración de SQLite a PostgreSQL

El cambio se realiza mediante exportación e importación, no mediante una conversión automática del archivo de base de datos.

• Preparar PostgreSQL: Proporcionar Postgres 13 o una versión más reciente, crear una base de datos propia y un usuario dedicado con todos los derechos sobre ella.
• Exportar workflows y credentials: Realizar la copia de seguridad mediante la CLI con n8n export:workflow --all --output=backup/ y n8n export:credentials --all --decrypted --output=backup/. La copia de seguridad descifrada de las credentials debe colocarse de inmediato en una ubicación protegida y no accesible públicamente.
• Cambiar las variables de entorno: Establecer DB_TYPE en postgresdb y configurar host, puerto, nombre de la base de datos, usuario, contraseña y, opcionalmente, el esquema mediante las variables DB_POSTGRESDB correspondientes.
• Iniciar n8n contra la base de datos Postgres vacía: n8n crea el esquema necesario por sí mismo en el primer arranque; no es necesario crear las tablas manualmente.
• Restaurar los datos: Importar los estados guardados con n8n import:workflow --separate --input=backup/ y n8n import:credentials --separate --input=backup/ y luego probar los workflows de forma aleatoria.

Esfuerzo y límites del cambio

El cambio no es un proceso de un solo clic, sino una pequeña ventana de mantenimiento: durante la exportación, la reconfiguración y la importación, n8n queda brevemente detenido, y los historiales de ejecución detallados no se migran automáticamente por la vía estándar. Para instalaciones pequeñas con pocos workflows, el esfuerzo es manejable; para instancias más grandes con muchas automatizaciones activas, merece la pena probar antes en una instancia de staging. Quien no quiera asumir esta etapa en solitario durante la operación en curso también puede hacerse acompañar externamente, por ejemplo en el marco de una consultoría de n8n a precio fijo.

Preguntas frecuentes sobre SQLite y PostgreSQL en n8n

¿A partir de cuántas ejecuciones por día debo cambiar a PostgreSQL?

n8n no indica una cifra general. Según la documentación, lo decisivo es más bien la arquitectura: en cuanto se planifican el modo cola o varias instancias main, Postgres se considera un requisito, independientemente del volumen exacto de ejecuciones.

¿Puedo simplemente seguir usando SQLite y aumentar solo el busy timeout?

Para instancias pequeñas y con poco paralelismo, sí, esto puede reducir sensiblemente los errores de bloqueo. Pero en cuanto se avanza hacia el modo cola o el multi-main, este ajuste ya no es suficiente según n8n.

¿Se pierden datos durante la migración?

La vía estándar mediante exportación e importación transfiere de forma fiable los workflows y las credentials. Los historiales de ejecución completos no están incluidos automáticamente; quien los necesite debe comprobarlo por separado antes de la migración.

¿Necesito obligatoriamente el modo cola para PostgreSQL?

No. También puede utilizar PostgreSQL en funcionamiento single-main sin modo cola, por ejemplo para evitar errores de bloqueo. El modo cola y el multi-main son niveles de ampliación propios que requieren adicionalmente Redis.

Encontrará más detalles sobre la elección de la base de datos y sobre las variables de entorno en la documentación de n8n sobre la selección de base de datos así como en la guía sobre el modo cola.