2 months ago
Since the beginning of last week, we've been experiencing several connection interruptions between the Postgres database and the primary n8n (the logs say "Database connection timed out"). Every time we run a workflow (on n8n that runs on railway), it fails, saying error 503. We don't know what to do; we've restarted, deployed, and updated, but nothing seems to change. It's very frustrating because it works very slowly and generates errors that cost us money. Can you help us understand what happened (it happened suddenly, everything was working fine before) and how to fix it? It's very urgent.
4 Replies
2 months ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • about 2 months ago
2 months ago
Yes, I have tried to update the image and then redeploy. Nothing change
2 months ago
"Database connection timed out" + 503s on n8n usually comes down to one of a few things, and the fact that it started suddenly after working fine points to something building up over time rather than a config you changed. A few questions and things to check;
- Are n8n and Postgres talking over private networking?
Make sure your n8n service connects to Postgres using the internal host (*.railway.internal), not the public proxy URL. Public connections are slower, rate-limited, and drop under load, that alone can cause exactly these timeouts. Check your DB_POSTGRESDB_HOST variable.
- Execution data bloat (very common cause of "suddenly slow")
n8n saves every workflow execution to Postgres by default. After a few weeks that table gets huge, queries slow down, and connections start timing out. Turn on pruning:
EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=168 # hours (7 days)
EXECUTIONS_DATA_PRUNE_MAX_COUNT=10000
This is the most likely culprit given it "happened suddenly after working fine."
- Connection pool / Postgres limits
On the Hobby plan the Postgres instance has limited memory. If n8n opens too many connections it hits the cap. Try capping the pool:
DB_POSTGRESDB_POOL_SIZE=4
- Resource check
Look at the Metrics tab for your Postgres service, if memory is maxing out and the service is restarting (OOM), that's your timeout. You may need to bump resources.
2 months ago
Problem Solution
-
Connection timeout Increase DB_POSTGRESDB_CONNECTION_TIMEOUT to 60000
-
Pool too small Increase DB_POSTGRESDB_POOL_SIZE to 10
-
Idle connection cut off Set DB_PING_INTERVAL_SECONDS to 1
-
DB slow due to accumulated data Enable EXECUTIONS_DATA_PRUNE
-
Recurring error daily Upgrade n8n to the latest version
