Postgres Trigger causing queueing and MaxClientsInSessionMode error in n8n (SQLite setup)

Questions
1

Describe the problem/error/question

Hi, I’m running a self-hosted n8n instance and facing multiple issues related to execution queueing and database connections.
Current setup:

  • Docker self-hosted n8n
  • SQLite as main DB
  • Postgres Trigger node connected to external DB (likely Supabase)
    Issues:
  1. Executions are getting stuck in queue (“Starting soon”)
  2. Encountered SQLite write lock errors
  3. Workflow activation fails with:
    “MaxClientsInSessionMode: max clients reached”
  4. Sometimes results in 502 Bad Gateway from Cloudflare
    What I’ve tried:
  • Increased concurrency limit to 5
  • Restarted container
  • Disabled workflow temporarily
    Question:
    What is the recommended setup for handling high-frequency Postgres triggers without hitting connection limits or queueing issues?
    Would switching fully to PostgreSQL for n8n solve this, or should I redesign the trigger flow?
    Thanks!

What is the error message (if any)?

Please share your workflow

(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:
1 Like
3

welcome to the n8n community @umairah_nabilah
for high-frequency Postgres Trigger workflows, I would move the n8n instance itself from SQLite to PostgreSQL and avoid queue mode on SQLite, then reduce trigger concurrency or redesign the flow with buffering/batching, because n8n explicitly does not recommend queue mode with SQLite and recommends PostgreSQL as the more robust backend for larger-scale deployments.

4

So that MaxClientsInSessionMode error is a Supabase thing, not an n8n thing really — you’re probably connecting through their session-mode pooler and the Postgres Trigger node needs a persistent connection which doesnt play nice with that. Switch to the direct connection string or the transaction-mode pooler (port 6543) and kill the stale idle connections in Supabase’s SQL editor, that should clear it up