Automation Stack for SMEs: n8n, Database, Vector Store, and Monitoring in the Big Picture

Anyone setting up n8n for a single project often gets by with a single instance and the bundled SQLite database. But as soon as the project grows into a production automation stack for an entire company, with multiple parallel workflows, growing data volume, and AI agents accessing company knowledge, this minimal configuration is no longer enough. The question then becomes which components actually belong together: database, queue, vector store, and monitoring are not optional extras, but the building blocks that turn a test setup into a resilient platform.

This article shows the big picture based on the official n8n documentation on scaling, database, and operations. As of: July 2026.

Why a single n8n instance is not enough for production

In standard operation, n8n runs as a single instance that receives triggers, executes workflows, and writes the results directly to its own database. For small teams and few workflows, this works reliably. However, as soon as several compute-intensive workflows run at the same time or many webhooks arrive in a short period, this single instance becomes a bottleneck: it has to receive triggers, manage executions, and handle the actual execution at the same time. According to the n8n documentation on scaling, the so-called queue mode offers the best scalability for this, because it distributes exactly these tasks across multiple instances. For an SME stack that outgrows the test phase, switching from single-instance operation to queue mode is therefore usually the first structural step.

The database: why PostgreSQL is the foundation

By default, n8n uses SQLite to store credentials, past executions, and workflows. This is convenient for a quick start, but it reaches its limits with concurrent access and growing data volume. For production environments, the n8n documentation on choosing a database recommends switching to PostgreSQL, which is configured via environment variables such as `DB_TYPE=postgresdb`. Important for permission management: n8n must be able to create and modify the schemas of the tables it uses itself, which is why the database user must be granted correspondingly broad permissions. PostgreSQL is therefore not only the more robust choice for many concurrent workflows, but also a mandatory prerequisite for the next building block.

Queue mode: main instance, workers, and Redis as the queue

Queue mode cleanly separates responsibilities. According to the guide to enabling queue mode, the main instance handles timers and webhook calls and creates an execution from them, but does not execute it itself. Instead, it passes the execution ID to Redis, which manages the queue as a message broker. Worker instances, each its own Node.js process, pick up tasks from this queue and carry out the actual workflows. For an SME stack, this means specifically:

• Additional workers can easily be added as needed to handle more load, and removed again when demand decreases.
• SQLite is explicitly not recommended for this operating mode; PostgreSQL from version 13 onward is the foundation.
• All instances, main and workers, must use the same encryption key so that credentials can be decrypted everywhere.
• The environment variable `EXECUTIONS_MODE=queue` must be set on all instances involved.

Anyone who only runs individual workflows occasionally does not need this effort right away. But as soon as several departments productively rely on the same n8n stack, splitting into a main instance and workers quickly pays off.

Vector store: making company knowledge searchable for AI agents

As soon as an automation stack is meant to support not only classic workflows but also AI agents with access to company knowledge, another building block comes into play: a vector store. For teams that are already using PostgreSQL anyway, the documentation on the PGVector node suggests an obvious solution: the PGVector extension turns the same PostgreSQL instance already running as the n8n database into a vector database at the same time. The node makes it possible to insert documents into a vector table, retrieve them selectively, and connect them directly as a tool to an AI agent, for example for a knowledge assistant that answers questions about internal documents. Alternatively, n8n also supports dedicated vector stores such as Qdrant, Weaviate, or Supabase, if the vector search should be deliberately separated from the operational workflow database, for example for performance or scaling reasons. For a lean SME stack, the shared PostgreSQL solution is usually the more pragmatic starting point, before a dedicated vector store service is even needed.

Monitoring and logging: visibility in live operation

A stack made up of multiple distributed components is only as good as the visibility you have into it. The documentation on monitoring n8n describes three endpoints designed exactly for this:

• `/healthz` reports with HTTP 200 that the instance is reachable, but says nothing about the database status. It is active by default on main servers.
• `/healthz/readiness` only returns HTTP 200 once the database is connected and all migrations are complete, a much more meaningful indicator that the instance can accept traffic.
• `/metrics` provides detailed metrics in Prometheus format, but is disabled by default and not available at all on n8n Cloud. It is enabled via `N8N_METRICS=true`, and additionally via `QUEUE_HEALTH_CHECK_ACTIVE=true` for worker health checks.

In addition, the documentation on logging governs how verbosely n8n logs. Via `N8N_LOG_LEVEL` you can set the level from `silent` to `debug`, with `info` as the default. Via `N8N_LOG_OUTPUT` you determine whether logs are written to the console, to a file, or to both, supplemented by `N8N_LOG_FILE_LOCATION` as well as limits for file size and the number of retained files. Especially in queue mode with multiple worker processes, clean log rotation is not a nice-to-have but the prerequisite for being able to trace at all, in the event of an error, which worker processed which execution and when.

The big picture: which components really belong together

In summary, a production-ready SME automation stack around n8n consists of several layers that build on one another:

• n8n main instance for triggers, webhooks, and the web interface.
• PostgreSQL as the central database for workflows, credentials, and execution history, from version 13 onward and with sufficient schema permissions.
• Redis as the queue, once queue mode with multiple workers is in use.
• n8n workers for the actual execution, horizontally scalable according to actual demand.
• Vector store, whether as a PGVector extension of the same PostgreSQL instance or as a dedicated service, once AI agents need to access company knowledge.
• Monitoring and logging via the `/healthz`, `/healthz/readiness`, and `/metrics` endpoints as well as structured logs, so operations remain traceable in the event of an error.

Not every company needs all layers from the start at once. For most SMEs, the sensible approach is to start with PostgreSQL as a solid foundation, add queue mode only once the load justifies it, and factor in monitoring from the beginning instead of adding it later. This way, the stack grows with actual requirements, and you retain control over cost, complexity, and operational risk, instead of building an architecture that is bigger than the actual problem. At NordFlux, we plan exactly this setup as part of our n8n consulting, from the initial server setup to operations with monitoring and an SLA. Where AI agents need to access internal company knowledge, our AI knowledge assistant adds exactly the vector store component needed for that.

Frequently asked questions

Is SQLite enough for running n8n in production?

For individual, low-traffic workflows, SQLite can be enough because it runs without additional infrastructure. As soon as several workflows run in parallel or queue mode is used, the n8n documentation explicitly recommends switching to PostgreSQL, since SQLite is not designed for distributed execution.

Do I need queue mode with multiple workers right away for an SME stack?

Not necessarily. Queue mode pays off once several compute-intensive workflows run at the same time or many webhooks arrive in a short period and a single instance becomes a bottleneck. For smaller setups with a few manageable workflows, a single main instance with PostgreSQL in the background is often enough.

Why does an n8n stack need a vector store at all?

A vector store becomes relevant as soon as AI agents in n8n need to access company-internal knowledge, such as documents, manuals, or support histories. The vector store stores this content in a searchable form, so that an agent finds the matching text excerpts for a query and incorporates them into its answer, instead of relying only on its training knowledge.

How do `/healthz` and `/healthz/readiness` differ?

`/healthz` only checks whether the n8n instance is basically reachable, but makes no statement about the database. `/healthz/readiness` goes a step further and only reports success once the database connection is established and all migrations are complete. For Kubernetes or Docker setups, the readiness endpoint is therefore usually the more meaningful indicator of whether an instance should actually accept traffic.

Can I build the automation stack step by step instead of all at once?

Yes, and for most SMEs that is even the more advisable approach. A realistic sequence is to start with a PostgreSQL database, set up monitoring from the start, add queue mode only once load grows, and add a vector store only once an AI agent with access to company knowledge is actually planned.