PostgreSQL vs SQLite para n8n en Producción: Cuál Elegir
Si estás montando n8n en producción, una de las primeras decisiones técnicas que debes tomar es la base de datos: SQLite (la opción por defecto) o PostgreSQL (la recomendada para producción). Esta guía explica las diferencias reales, cuándo importa cada una y cómo migrar de SQLite a PostgreSQL si ya tienes n8n funcionando.
La respuesta rápida
SQLite está bien para pruebas, uso personal con pocos workflows y entornos de desarrollo. PostgreSQL es la base de datos correcta para producción, especialmente si tienes muchos workflows activos, webhooks concurrentes, un equipo usando n8n o simplemente quieres que funcione de forma estable sin sorpresas.
Si estás montando n8n desde cero con tu VPS para N8N, empieza directamente con PostgreSQL. Es más trabajo inicial pero te evita una migración posterior y problemas de rendimiento en producción.
Qué almacena N8N en la base de datos
Para entender por qué importa la elección de base de datos, hay que saber qué almacena n8n:
- Workflows: la definición de todos tus flujos de automatización
- Credenciales: tokens, claves de API y contraseñas de servicios (cifradas)
- Historial de ejecuciones: cada vez que un workflow se ejecuta, n8n guarda el resultado (éxito, error, datos de entrada y salida)
- Usuarios y sesiones: si tienes múltiples usuarios
- Variables de entorno globales y configuraciones
El historial de ejecuciones es lo que más crece con el tiempo. En una instalación activa con varios workflows que se ejecutan decenas de veces al día, puede generar cientos de miles de registros en pocas semanas.
SQLite: ventajas y limitaciones
Ventajas
Zero configuration. SQLite no requiere instalación ni configuración. n8n lo usa por defecto, crea un archivo .db en el directorio de datos y listo. Ideal para empezar rápido y en entornos de desarrollo.
Sin procesos adicionales. No ocupa RAM adicional. No hay un proceso de base de datos corriendo en segundo plano. En un VPS pequeño (1-2 GB RAM), esto puede marcar la diferencia.
Fácil de hacer backup. Un backup de SQLite es literalmente copiar un archivo.
Limitaciones
Sin concurrencia real. SQLite usa bloqueos a nivel de archivo. Cuando múltiples workflows intentan escribir en la base de datos al mismo tiempo (lo que ocurre constantemente en producción), generan colas de espera. En n8n con alta carga, esto se traduce en workflows que tardan más en ejecutarse de lo esperado.
Escala mal con el historial de ejecuciones. Cuando la base de datos SQLite supera unos pocos centenares de MB, las consultas de historial empiezan a ir más lentas. Si no configuras la limpieza del historial, puede llegar a varios GB y ralentizar el sistema notablemente.
Sin VACUUM automático eficiente. SQLite no recupera espacio en disco automáticamente después de borrar registros. Necesitas ejecutar VACUUM manualmente para que el archivo de la base de datos se comprima.
No soporta múltiples workers. Si en algún momento quieres escalar n8n con múltiples workers (para procesar colas de ejecuciones en paralelo), SQLite no es compatible. Es un requisito de arquitectura que solo PostgreSQL cumple.
PostgreSQL: ventajas y cuándo es necesario
Ventajas
Concurrencia real. PostgreSQL gestiona múltiples escrituras simultáneas con bloqueos a nivel de fila, no de archivo. Los workflows concurrentes no se bloquean entre sí y la cola de ejecuciones fluye sin esperas.
Rendimiento con grandes volúmenes de datos. PostgreSQL tiene un optimizador de consultas sofisticado e índices eficientes. Una base de datos con millones de registros de historial funciona igual de bien que con miles.
VACUUM y AUTOVACUUM automático. PostgreSQL recupera espacio en disco automáticamente. El mantenimiento es prácticamente transparente.
Compatibilidad con múltiples workers. Si tu instalación de n8n crece y necesitas escalar con workers paralelos (necesario para colas con miles de ejecuciones simultáneas), PostgreSQL es el requisito.
Backups online con pg_dump. Puedes hacer backups de PostgreSQL mientras n8n está funcionando, sin parar el servicio ni arriesgar datos inconsistentes.
Cuándo es necesario PostgreSQL
- Producción con más de 2-3 workflows activos que se ejecutan frecuentemente
- Webhooks que reciben muchas peticiones por hora
- Múltiples usuarios usando n8n simultáneamente
- Más de unos pocos meses de historial de ejecuciones sin limpieza
- Cualquier instalación que sea crítica para el negocio
Comparativa directa
| SQLite | PostgreSQL | |
|---|---|---|
| Instalación | Automática, zero-config | Requiere instalar y configurar |
| Concurrencia | Baja (bloqueos a nivel archivo) | Alta (bloqueos a nivel fila) |
| Rendimiento con volumen | Degrada con el tiempo | Constante |
| Uso de RAM | Mínimo | ~50-200 MB extra |
| Múltiples workers | ✗ | ✓ |
| Backup en caliente | Riesgoso | ✓ con pg_dump |
| Recomendado para | Dev / pruebas / uso personal ligero | Producción |
| Escala a | ~1 millón de registros bien | Cientos de millones sin problema |
Cómo configurar PostgreSQL para N8N desde cero
Si estás instalando n8n nuevo, usa el docker-compose.yml de la guía de instalación de n8n con Docker que ya incluye PostgreSQL.
Si prefieres instalar PostgreSQL directamente en el servidor (sin Docker):
apt install -y postgresql postgresql-contrib systemctl start postgresql systemctl enable postgresql
Crea la base de datos y el usuario para n8n:
sudo -u postgres psql
Dentro de psql:
CREATE DATABASE n8n; CREATE USER n8n WITH ENCRYPTED PASSWORD 'tu_contraseña_segura'; GRANT ALL PRIVILEGES ON DATABASE n8n TO n8n; \q
Configura n8n para usar PostgreSQL añadiendo estas variables de entorno:
DB_TYPE=postgresdb DB_POSTGRESDB_HOST=localhost DB_POSTGRESDB_PORT=5432 DB_POSTGRESDB_DATABASE=n8n DB_POSTGRESDB_USER=n8n DB_POSTGRESDB_PASSWORD=tu_contraseña_segura
Cómo migrar de SQLite a PostgreSQL en N8N existente
Si ya tienes n8n funcionando con SQLite y quieres migrar a PostgreSQL, el proceso es:
1. Para n8n
cd /opt/n8n && docker compose stop n8n
2. Instala PostgreSQL (si no lo tienes ya)
Si usas Docker, añade el servicio al docker-compose.yml como en el ejemplo de la guía de instalación.
Si lo instalas directamente:
apt install -y postgresql sudo -u postgres psql -c "CREATE DATABASE n8n;" sudo -u postgres psql -c "CREATE USER n8n WITH ENCRYPTED PASSWORD 'tu_contraseña';" sudo -u postgres psql -c "GRANT ALL PRIVILEGES ON DATABASE n8n TO n8n;"
3. Exporta los datos de SQLite
N8N incluye un comando de exportación:
docker exec -it n8n-n8n-1 n8n export:workflow --all --output=/home/node/.n8n/workflows.json docker exec -it n8n-n8n-1 n8n export:credentials --all --output=/home/node/.n8n/credentials.json
Copia los archivos exportados:
docker cp n8n-n8n-1:/home/node/.n8n/workflows.json /tmp/ docker cp n8n-n8n-1:/home/node/.n8n/credentials.json /tmp/
4. Actualiza las variables de entorno en docker-compose.yml
Edita /opt/n8n/docker-compose.yml y añade o actualiza las variables de entorno de n8n:
environment: - DB_TYPE=postgresdb - DB_POSTGRESDB_HOST=postgres - DB_POSTGRESDB_PORT=5432 - DB_POSTGRESDB_DATABASE=n8n - DB_POSTGRESDB_USER=n8n - DB_POSTGRESDB_PASSWORD=tu_contraseña
5. Arranca n8n con la nueva configuración
docker compose up -d
n8n creará automáticamente las tablas en PostgreSQL.
6. Importa los workflows y credenciales
docker cp /tmp/workflows.json n8n-n8n-1:/tmp/ docker cp /tmp/credentials.json n8n-n8n-1:/tmp/ docker exec -it n8n-n8n-1 n8n import:workflow --input=/tmp/workflows.json docker exec -it n8n-n8n-1 n8n import:credentials --input=/tmp/credentials.json
7. Verifica la migración
Accede a tu n8n en el navegador y verifica que todos los workflows y credenciales están presentes. Activa los workflows que tenías activos y verifica que ejecutan correctamente.
Nota importante: El historial de ejecuciones anterior no se migra con este método. Solo se migran workflows y credenciales. Si necesitas el historial completo, hay herramientas de migración directa de SQLite a PostgreSQL, pero el proceso es más complejo.
Mantenimiento de PostgreSQL en N8N
Controlar el tamaño del historial de ejecuciones
El historial de ejecuciones es lo que más hace crecer la base de datos. Configura un límite en n8n:
En Settings → Executions:
– Save data of successful executions: «Latest 1000» o un número razonable para tu caso
– Save data of error executions: «All» (para poder depurar errores)
– Save data of manual executions: «Latest 100»
También puedes configurar la retención a nivel de variable de entorno:
EXECUTIONS_DATA_PRUNE=true EXECUTIONS_DATA_MAX_AGE=336 # horas (14 días)
Backup de PostgreSQL
Para hacer backup de la base de datos de n8n:
docker exec -t n8n-postgres-1 pg_dump -U n8n n8n > /backup/n8n_$(date +%Y%m%d_%H%M).sql
Automatiza con cron (crontab -e):
0 3 * * * docker exec -t n8n-postgres-1 pg_dump -U n8n n8n | gzip > /backup/n8n_$(date +\%Y\%m\%d).sql.gz
Verificar el tamaño de la base de datos
docker exec -t n8n-postgres-1 psql -U n8n -c "\l+"
O más específico:
docker exec -t n8n-postgres-1 psql -U n8n -d n8n -c "SELECT pg_size_pretty(pg_database_size('n8n'));"
Conclusión
Para cualquier instalación de n8n que no sea estrictamente para pruebas o uso personal muy ligero, PostgreSQL es la elección correcta. La diferencia en configuración inicial es de 10-15 minutos, y los beneficios en estabilidad, rendimiento bajo carga y escalabilidad justifican completamente ese tiempo adicional.
Si estás montando n8n desde cero en un VPS, usa el docker-compose con PostgreSQL incluido desde el principio. Si ya tienes n8n con SQLite y notas lentitud o problemas de concurrencia, la migración descrita en esta guía es el siguiente paso lógico.
Para los recursos del VPS, n8n con PostgreSQL funciona bien desde 2 GB de RAM (VPS I de BlumHost). Para producción con varios workflows activos, 4 GB de RAM (VPS II) es la configuración recomendada. Consulta los planes VPS para N8N con los requisitos detallados por tipo de uso.
¿Tienes dudas sobre la configuración de PostgreSQL para n8n o necesitas ayuda con la migración? Contacta con el soporte de BlumHost.
