# Prevent n8n from overwhelming PostgreSQL when workflow executions increase suddenly **URL:** \ **Category:** Questions\ **Created:** [August 20, 2026, 7:49am UTC](https://community.n8n.io/t/prevent-n8n-from-overwhelming-postgresql-when-workflow-executions-increase-suddenly/308540 "2026-08-20T07:49:12Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Decoure\_Ryan](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/decoure_ryan/32/51867_2.png) [@Decoure\_Ryan](https://community.n8n.io/u/Decoure_Ryan)\ **Post date:** [August 20, 2026, 7:49am UTC](https://community.n8n.io/t/prevent-n8n-from-overwhelming-postgresql-when-workflow-executions-increase-suddenly/308540/1 "2026-08-20T07:49:13Z")
I’m running multiple n8n workflows that read and update PostgreSQL. During traffic spikes, many executions start at the same time and PostgreSQL begins showing high CPU usage and too many active connections. I’m currently querying like this: SELECT id, status FROM orders WHERE status = ‘pending’ ORDER BY created\_at LIMIT 100; I’m considering limiting n8n concurrency and adding indexes: CREATE INDEX orders\_pending\_idx ON orders (status, created\_at); Would you prioritize n8n concurrency limits, better indexes, connection pooling, batching, or a combination of these? ## Describe the problem/error/question ## What is the error message (if any)? ## Please share your workflow ```auto (Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.) ``` ## Share the output returned by the last node ## Information on your n8n setup - **n8n version:** - **Database (default: SQLite):** - **n8n EXECUTIONS\_PROCESS setting (default: own, main):** - **Running n8n via (Docker, npm, n8n cloud, desktop app):** - **Operating system:** ---
**Author:** ![n8n](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/n8n/32/196425_2.png) [@n8n](https://community.n8n.io/u/n8n)\ **Post date:** [August 20, 2026, 7:49am UTC](https://community.n8n.io/t/prevent-n8n-from-overwhelming-postgresql-when-workflow-executions-increase-suddenly/308540/2 "2026-08-20T07:49:44Z")
Hey @Decoure_Ryan, while you wait for a response, here are some things that might help: > **Suggested resources** > > _Automatically matched to your question._ > > **Docs:** > > - [Enable queue mode](https://docs.n8n.io/deploy/host-n8n/configure-n8n/scaling/enable-queue-mode#concurrency-and-scaling-recommendations) > - [Database](https://docs.n8n.io/deploy/host-n8n/configure-n8n/basic-configuration/use-environment-variables/database#postgresql) > - [Control concurrency](https://docs.n8n.io/deploy/host-n8n/configure-n8n/scaling/control-concurrency) > > **Forum:** > > - [How to increase the default limit 10 of parallel executions?](https://community.n8n.io/t/how-to-increase-the-default-limit-10-of-parallel-executions/307124) > - [Managing n8n concurrency](https://community.n8n.io/t/managing-n8n-concurrency/239170) > - [Scaling and performance](https://community.n8n.io/t/scaling-and-performance/219750) @anon45958619, @zenithflare, @Websensepro - you’ve helped with similar issues before, can you take a look? _Automatically suggested by n8n’s community bot. It’s a pilot - [please share feedback here](https://community.n8n.io/t/pilot-forum-helper-bot/304669)._ ---
**Author:** ![Niffzy](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/niffzy/32/158156_2.png) [@Niffzy](https://community.n8n.io/u/Niffzy)\ **Post date:** [August 20, 2026, 7:54am UTC](https://community.n8n.io/t/prevent-n8n-from-overwhelming-postgresql-when-workflow-executions-increase-suddenly/308540/3 "2026-08-20T07:54:53Z")
Hi @Decoure_Ryan I’d handle this with a combination of n8n concurrency control, proper PostgreSQL indexing, batching, and connection pooling. The main thing is not to let n8n send more work to PostgreSQL than the database can comfortably handle Control n8n concurrency If hundreds of workflows start at once, PostgreSQL can quickly become overloaded. Set a reasonable concurrency limit and increase it gradually while monitoring performance. Make the query efficient Your index is a good start: CREATE INDEX orders\_pending\_idx ON orders (status, created\_at); This helps PostgreSQL find pending orders much faster. Use smaller batches Instead of pulling thousands of records at once: SELECT id, status FROM orders WHERE status = ‘pending’ ORDER BY created\_at LIMIT 100; Processe a manageable batch, then fetch the next one. Use connection pooling If you have many concurrent n8n executions, connection pooling helps prevent PostgreSQL from being flooded with connections. ---
**Author:** ![kjooleng](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/kjooleng/32/184045_2.png) [@kjooleng](https://community.n8n.io/u/kjooleng)\ **Post date:** [August 20, 2026, 7:56am UTC](https://community.n8n.io/t/prevent-n8n-from-overwhelming-postgresql-when-workflow-executions-increase-suddenly/308540/4 "2026-08-20T07:56:29Z")
Hi @Decoure_Ryan To address your immediate performance issues, prioritize adding the composite index on `(status, created_at)`. Your current query likely triggers a full table scan, which causes CPU spikes as the table grows. By implementing this index, PostgreSQL can instantly locate “pending” rows and retrieve them in the correct order without the heavy computational cost of a manual sort, providing the fastest relief for your CPU usage. To resolve the “too many connections” error, implement a connection pooler like PgBouncer between n8n and your PostgreSQL instance. Because n8n’s high-concurrency model attempts to open a new connection for many simultaneous executions, it can quickly exhaust the database’s connection limit. Using PgBouncer in “transaction pooling” mode allows hundreds of n8n workflows to share a much smaller, stable pool of actual database connections, significantly reducing overhead and preventing connection errors. Finally, implement architectural guardrails by combining n8n concurrency limits with batch processing. Limiting the number of concurrent executions ensures that even during massive traffic spikes, the total pressure on the database remains within a predictable range. For long-term scalability, transition from many small, frequent workflows to a “master” workflow that fetches and processes larger batches of data at once, which minimizes the total number of database requests and maximizes efficiency. ---
**Author:** ![Lopez](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/lopez/32/192785_2.png) [@Lopez](https://community.n8n.io/u/Lopez)\ **Post date:** [August 20, 2026, 8:02am UTC](https://community.n8n.io/t/prevent-n8n-from-overwhelming-postgresql-when-workflow-executions-increase-suddenly/308540/5 "2026-08-20T08:02:54Z")
Hi @Decoure_Ryan Adding on Prioritize the fixes in this order: 1. **Use** `SKIP LOCKED` **and a partial index:** 2. **Add connection pooling:** Put **PgBouncer** (in transaction mode) in front of PostgreSQL or limit n8n’s connection pool size (`DB_POSTGRESDB_POOL_SIZE=10`). 3. **Throttle execution concurrency:** If using Queue Mode (Redis), set `N8N_CONCURRENCY_PRODUCTION_LIMIT=10` on your workers. If on single-instance, process records sequentially in batches rather than spawning dozens of parallel executions. Hope this help. ---
**Author:** ![Anshul\_Namdev](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/anshul_namdev/32/178229_2.png) [@Anshul\_Namdev](https://community.n8n.io/u/Anshul_Namdev)\ **Post date:** [August 20, 2026, 8:56am UTC](https://community.n8n.io/t/prevent-n8n-from-overwhelming-postgresql-when-workflow-executions-increase-suddenly/308540/6 "2026-08-20T08:56:40Z")
Hi @Decoure_Ryan If n8n keeps its own data in that same Postgres instance, part of the spike is n8n writing about itself. Every production execution inserts a row into `execution_entity` and the whole run payload into `execution_data`, and that write volume tracks execution count regardless of how the orders query is tuned. Check with `SELECT pg_size_pretty(pg_total_relation_size('execution_data'));` and if that table dominates, stop saving successful runs and shorten retention: ```auto EXECUTIONS_DATA_SAVE_ON_SUCCESS=none EXECUTIONS_DATA_MAX_AGE=72 ``` > **[Manage execution data | Deploy | n8n Docs](https://docs.n8n.io/deploy/host-n8n/configure-n8n/scaling/manage-execution-data)** ---
**Author:** ![system](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/system/32/195824_2.png) [@system](https://community.n8n.io/u/system)\ **Post date:** [August 27, 2026, 8:57am UTC](https://community.n8n.io/t/prevent-n8n-from-overwhelming-postgresql-when-workflow-executions-increase-suddenly/308540/7 "2026-08-27T08:57:28Z")
Closed on August 27, 2026, 8:57am UTC This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.