How much server does n8n need? RAM, CPU, and storage by workflow load

How much server n8n needs depends less on the sheer number of users than on the number of parallel executions and the amount of binary data flowing through the workflows. n8n itself tested a single instance with 4 GB RAM (type ECS c5a.large, main mode with Postgres) in its own benchmark and reached up to 220 workflow executions per second, though with a very simple workflow consisting of a webhook trigger and an Edit Fields node. For most SME automations with more complex nodes, file processing, or AI calls, this is not a realistic sustained value but an upper limit under lab conditions. As of: August 2026.

Is a small instance enough to get started?

For getting started, a small to medium instance is usually enough, as long as workflows don't run continuously in parallel and with heavy binary loads. In n8n's own test, a single instance with 4 GB RAM remained stable up to a certain load level, but response times rose significantly under higher load, peaking at over 100 seconds, while processing continued in the background. This shows that a small instance still processes the load in the end, but no longer within a useful time for synchronous webhook responses. Details on the test setup are provided by the performance documentation from n8n.

When does SQLite become a problem?

SQLite becomes a problem at the latest when you want to scale to multiple n8n processes. According to n8n, SQLite is not intended for Queue Mode with multiple workers; instead, a Postgres database is required, one that both the main instance and all worker instances can access. So if you expect to grow, you should plan with Postgres instead of SQLite from the start, even though a single instance with SQLite initially works for small, non-critical setups.

When is switching to Queue Mode worthwhile?

Queue Mode is worthwhile as soon as a single instance reaches its limits, for example due to many simultaneous users, many parallel executions, or load spikes on webhooks. In Queue Mode, a main instance handles triggers, webhooks, and the interface, while separate worker instances handle the actual executions; in addition, Redis is required as a message broker. Each worker processes up to 10 jobs simultaneously by default, but n8n recommends limiting the concurrency per worker to at least 5 so that the database connection pool is not exhausted. The details of how to configure this are described in the n8n documentation on Queue Mode.

What changes with large binary data?

Binary data such as PDFs or images changes the calculation much more significantly than pure JSON processing, because it creates additional memory and I/O demands. According to the documentation, storing binary data on the local file system is not supported in Queue Mode; instead, external S3-compatible storage is recommended. Anyone processing many documents should factor this in from the start when planning the server, rather than only noticing it once the disk or memory is full.

How do I size this for my own case?

The most reliable way to size your setup is to test your own, realistic workflow instead of relying on generic numbers. n8n itself explicitly points out that actual performance depends on the workflow type, available resources, and configuration, and recommends running your own benchmarks with its in-house test framework. For production use on your own server hosted in Germany or the EU, we at NordFlux help with the n8n setup including choosing the right server and database.

Frequently asked questions about n8n server sizing

Is a small cloud instance with little RAM enough for n8n?

For simple, non-parallel workflows, a small instance can be sufficient, as n8n's own test with 4 GB RAM shows. However, as soon as several workflows run simultaneously or binary data is processed, the demand increases noticeably, which is why running your own test under realistic load makes more sense than a blanket recommendation.

Do I absolutely need Queue Mode?

No, for smaller setups with manageable parallel load, a single instance is sufficient. According to n8n, Queue Mode becomes relevant mainly when an instance reaches its scaling limits and additional workers are needed to distribute the load.

What is the maximum number of executions per second n8n can handle?

In its own benchmark, n8n itself cites up to 220 workflow executions per second on a single instance, measured with a very simple test workflow. For more complex workflows with more nodes, external API calls, or binary data, the realistic value is, based on experience, significantly lower.

Does n8n run with SQLite in production?

SQLite is generally usable for a single instance with manageable load. However, according to the documentation, SQLite is not intended for Queue Mode with multiple workers; Postgres is required there.