Handling PostgreSQL Failover in Production with n8n

Questions
1

HELLO
I’m planning for high availability and wanted to ask how others are handling PostgreSQL failover in production with n8n.
My current architecture is something like:Load Balancer
↓
Multiple n8n Workers
↓
PostgreSQL
I’m thinking ahead about scenarios where the primary PostgreSQL server becomes unavailable. My main concerns are:
Preventing workflow failures during failover
Minimizing downtime
Avoiding duplicate executions after reconnecting
Ensuring workers reconnect cleanly
I’ve looked into:
PostgreSQL streaming replication
Patroni
PgBouncer
Managed PostgreSQL services with automatic failover

Describe the problem/error/question

What failover strategy are you using?
How does n8n behave during a database failover?
Have you experienced issues with reconnecting workers or duplicate executions?
Any lessons learned or recommendations for building a highly available PostgreSQL setup?
I’d really appreciate hearing about real-world production experiences.

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:
2

Hi @Greg_John use PostgreSQL replication with automatic failover rather than relying on a single database server.

n8n Workers → PgBouncer → PostgreSQL Primary
↓
PostgreSQL Replica

If the primary database fails, the replica can be promoted automatically, allowing workers to reconnect with minimal downtime.

Best practices
Enable automatic failover (Patroni or a managed PostgreSQL service)
Use PgBouncer for connection pooling
Monitor replication lag and database health
Test failover regularly to ensure recovery works as expected

For n8n

Design your workflows to be idempotent. If a workflow retries after a failover, it shouldn’t create duplicate records or repeat side effects.

3

Thanks @Niffzy For the reply

Got it sorted out