Pila de automatización para pymes: n8n, base de datos, vector store y monitorización en conjunto

Quien configura n8n para un solo proyecto suele arreglárselas con una única instancia y la base de datos SQLite incluida. Pero en cuanto el proyecto se convierte en una pila de automatización productiva para toda una empresa, con varios workflows paralelos, un volumen de datos creciente y agentes de IA que acceden al conocimiento de la empresa, esta configuración mínima ya no es suficiente. Entonces surge la pregunta de qué componentes realmente van juntos: base de datos, cola, vector store y monitorización no son extras opcionales, sino los bloques que convierten una configuración de prueba en una plataforma sólida.

Este artículo muestra la visión de conjunto a partir de la documentación oficial de n8n sobre escalado, base de datos y operación. Actualizado a julio de 2026.

Por qué una única instancia de n8n no basta para producción

En funcionamiento estándar, n8n se ejecuta como una única instancia que recibe triggers, ejecuta workflows y escribe los resultados directamente en su propia base de datos. Para equipos pequeños y pocos workflows, esto funciona de forma fiable. Pero en cuanto se ejecutan varios workflows que consumen muchos recursos al mismo tiempo o llegan muchos webhooks en poco tiempo, esta única instancia se convierte en un cuello de botella: tiene que recibir triggers, gestionar ejecuciones y, al mismo tiempo, asumir la ejecución propiamente dicha. Según la documentación de n8n sobre escalado, el llamado modo cola ofrece la mejor escalabilidad para esto, porque distribuye precisamente estas tareas entre varias instancias. Para una pila de pymes que supera la fase de pruebas, el paso del funcionamiento en instancia única al modo cola suele ser, por tanto, el primer paso estructural.

La base de datos: por qué PostgreSQL es el fundamento

Por defecto, n8n utiliza SQLite para almacenar credenciales, ejecuciones pasadas y workflows. Esto resulta práctico para empezar rápido, pero alcanza sus límites con accesos concurrentes y un volumen de datos creciente. Para entornos de producción, la documentación de n8n sobre la elección de la base de datos recomienda pasar a PostgreSQL, que se configura mediante variables de entorno como `DB_TYPE=postgresdb`. Importante para la gestión de permisos: n8n debe poder crear y modificar por sí mismo los esquemas de las tablas utilizadas, por lo que hay que otorgar al usuario de la base de datos permisos suficientemente amplios. PostgreSQL no es, por tanto, solo la opción más robusta para muchos workflows simultáneos, sino también un requisito indispensable para el siguiente componente.

Modo cola: instancia principal, workers y Redis como cola

El modo cola separa claramente las responsabilidades. Según la guía para activar el modo cola, la instancia principal se encarga de los timers y las llamadas webhook y crea una ejecución a partir de ellos, pero no la ejecuta ella misma. En su lugar, pasa el ID de ejecución a Redis, que gestiona la cola como message broker. Las instancias worker, cada una un proceso Node.js independiente, recogen tareas de esta cola y llevan a cabo los workflows propiamente dichos. Para una pila de pymes, esto significa en concreto:

• Se pueden añadir workers adicionales fácilmente cuando sea necesario para procesar más carga, y volver a retirarlos cuando la demanda disminuye.
• SQLite no se recomienda explícitamente para este modo de funcionamiento; PostgreSQL a partir de la versión 13 es la base.
• Todas las instancias, principal y workers, deben usar la misma clave de cifrado para que las credenciales puedan descifrarse en todas partes.
• La variable de entorno `EXECUTIONS_MODE=queue` debe estar definida en todas las instancias implicadas.

Quien solo ejecuta workflows individuales de forma ocasional no necesita este esfuerzo de inmediato. Pero en cuanto varios departamentos utilizan de forma productiva la misma pila n8n, la separación en instancia principal y workers resulta rentable rápidamente.

Vector store: hacer que el conocimiento de la empresa sea consultable para agentes de IA

En cuanto una pila de automatización debe dar soporte no solo a workflows clásicos, sino también a agentes de IA con acceso al conocimiento de la empresa, entra en juego otro componente: un vector store. Para equipos que ya utilizan PostgreSQL, la documentación del nodo PGVector ofrece una solución evidente: la extensión PGVector convierte la misma instancia de PostgreSQL, que ya funciona como base de datos de n8n, en una base de datos vectorial al mismo tiempo. El nodo permite insertar documentos en una tabla vectorial, recuperarlos de forma específica y conectarlos directamente como herramienta a un agente de IA, por ejemplo para un asistente de conocimiento que responde preguntas sobre documentos internos. n8n también admite vector stores dedicados como Qdrant, Weaviate o Supabase, si la búsqueda vectorial debe separarse deliberadamente de la base de datos operativa de workflows, por ejemplo por motivos de rendimiento o escalado. Para una pila de pymes sencilla, la solución PostgreSQL compartida suele ser el punto de partida más pragmático, antes de que sea realmente necesario un servicio de vector store propio.

Monitorización y logging: visibilidad en producción

Una pila formada por varios componentes distribuidos es tan buena como la visibilidad que se tenga sobre ella. La documentación sobre la monitorización de n8n describe tres endpoints diseñados exactamente para esto:

• `/healthz` informa con HTTP 200 de que la instancia es accesible, pero no dice nada sobre el estado de la base de datos. Está activo por defecto en los servidores principales.
• `/healthz/readiness` solo devuelve HTTP 200 cuando la base de datos está conectada y todas las migraciones se han completado, un indicador mucho más fiable de que la instancia puede aceptar tráfico.
• `/metrics` ofrece métricas detalladas en formato Prometheus, pero está desactivado por defecto y no está disponible en absoluto en n8n Cloud. Se activa mediante `N8N_METRICS=true`, y para los health checks de los workers, adicionalmente mediante `QUEUE_HEALTH_CHECK_ACTIVE=true`.

Además, la documentación sobre logging regula con qué nivel de detalle registra n8n. Mediante `N8N_LOG_LEVEL` se puede ajustar el nivel de `silent` a `debug`, siendo `info` el valor por defecto. Mediante `N8N_LOG_OUTPUT` determinas si los logs se escriben en la consola, en un archivo o en ambos, complementado con `N8N_LOG_FILE_LOCATION`, así como límites de tamaño de archivo y número de archivos conservados. Especialmente en modo cola con varios procesos worker, una rotación de logs limpia no es un extra opcional, sino el requisito para poder determinar, en caso de error, qué worker procesó qué ejecución y cuándo.

La visión de conjunto: qué componentes van realmente juntos

En resumen, una pila de automatización productiva para pymes en torno a n8n consta de varias capas que se apoyan unas en otras:

• Instancia principal de n8n para triggers, webhooks y la interfaz web.
• PostgreSQL como base de datos central para workflows, credenciales e historial de ejecuciones, a partir de la versión 13 y con permisos de esquema suficientes.
• Redis como cola, en cuanto se usa el modo cola con varios workers.
• Workers de n8n para la ejecución propiamente dicha, escalables horizontalmente según la demanda real.
• Vector store, ya sea como extensión PGVector de la misma instancia de PostgreSQL o como servicio dedicado, en cuanto los agentes de IA deban acceder al conocimiento de la empresa.
• Monitorización y logging a través de los endpoints `/healthz`, `/healthz/readiness` y `/metrics`, así como logs estructurados, para que la operación siga siendo trazable en caso de error.

No todas las empresas necesitan todas las capas desde el principio. Para la mayoría de las pymes, el enfoque razonable es empezar con PostgreSQL como base sólida, incorporar el modo cola solo cuando la carga lo justifique, y tener en cuenta la monitorización desde el principio en lugar de añadirla después. Así, la pila crece con los requisitos reales, y mantienes el control sobre los costes, la complejidad y el riesgo operativo, en lugar de construir una arquitectura más grande que el problema real. En NordFlux planificamos exactamente esta configuración en el marco de nuestra consultoría de n8n, desde la primera configuración del servidor hasta la operación con monitorización y SLA. Cuando los agentes de IA deben acceder al conocimiento interno de la empresa, nuestro asistente de conocimiento con IA añade exactamente el componente de vector store necesario para ello.

Preguntas frecuentes

¿Es suficiente SQLite para el uso en producción de n8n?

Para workflows individuales con poco tráfico, SQLite puede ser suficiente porque funciona sin infraestructura adicional. En cuanto se ejecutan varios workflows en paralelo o se usa el modo cola, la documentación de n8n recomienda explícitamente pasar a PostgreSQL, ya que SQLite no está diseñado para la ejecución distribuida.

¿Necesito de inmediato el modo cola con varios workers para una pila de pymes?

No necesariamente. El modo cola resulta rentable en cuanto se ejecutan varios workflows que consumen muchos recursos al mismo tiempo o llegan muchos webhooks en poco tiempo y una única instancia se convierte en un cuello de botella. Para configuraciones más pequeñas con pocos workflows manejables, a menudo basta con una única instancia principal con PostgreSQL en segundo plano.

¿Para qué necesita una pila n8n un vector store?

Un vector store se vuelve relevante en cuanto los agentes de IA en n8n deben acceder a conocimiento interno de la empresa, como documentos, manuales o historiales de soporte. El vector store almacena este contenido en una forma consultable, de modo que un agente encuentra los fragmentos de texto adecuados para una consulta y los incorpora a su respuesta, en lugar de basarse solo en su conocimiento de entrenamiento.

¿En qué se diferencian `/healthz` y `/healthz/readiness`?

`/healthz` solo comprueba si la instancia de n8n es accesible en general, pero no dice nada sobre la base de datos. `/healthz/readiness` va un paso más allá y solo informa de éxito cuando la conexión a la base de datos está establecida y todas las migraciones se han completado. Para configuraciones de Kubernetes o Docker, el endpoint de readiness suele ser, por tanto, el indicador más fiable de si una instancia debería aceptar tráfico realmente.

¿Puedo construir la pila de automatización paso a paso en lugar de todo a la vez?

Sí, y esa es incluso la vía más recomendable para la mayoría de las pymes. Una secuencia realista consiste en empezar con una base de datos PostgreSQL, configurar la monitorización desde el principio, incorporar el modo cola solo cuando aumente la carga, y añadir un vector store solo cuando realmente esté previsto un agente de IA con acceso al conocimiento de la empresa.