3 months ago
Hi,
I’m experiencing severe instability with my Postgres instance on Railway.
I am using the default internal connection URL provided by Railway:
postgresql://postgres:<password>@postgres.railway.internal:5432/railwayNo parameters added — exactly as provided.
With this connection string, the backend starts failing continuously with:
502 Bad Gateway – Application failed to respondPrisma connection timeouts
Frontend failing to fetch API data
General DB connection failures
Postgres logs show ongoing crashes and connection resets:
Examples from the logs:
could not receive data from client: Connection reset by peercould not accept SSL connection: EOF detectedRepeated database restarts and recovery cycles:
database system was not properly shut down; automatic recovery in progressredo starts at…invalid record length… expected at least 24, got 0database system is ready to accept connections
These events happen repeatedly every few minutes.
It appears the Postgres server is crashing, restarting, and entering recovery loops.
This behavior began after removing the previously appended sslmode=require, but the issue persists even though this is an internal-only connection (postgres.railway.internal) which should not require SSL.
At this point, the database is unstable and causing production outages.
Thanks in advance for your help diagnosing this.
Pinned Solution
3 months ago
Hi! Sorry you’re dealing with this, the issues you’re describing usually come down to two common causes on Railway:
1. Too many database connections
Railway Postgres has a relatively low connection limit. When your app exceeds it, you’ll see errors like:
• connection reset by peer
• Prisma timeouts
• 502 errors from your backend
• Postgres restarting or going into recovery
Prisma, in particular, opens multiple connections per instance. So if you have:
• multiple backend replicas
• a serverless frontend hitting your API frequently
• long-lived Prisma clients
…your database can get overwhelmed pretty quickly.
How to fix it
Use Prisma’s connection pooling by adding ?pgbouncer=true to your Postgres URL — even when using internal connections:
postgresql://postgres:<password>@postgres.railway.internal:5432/railway?pgbouncer=true
After updating your URL, redeploy your backend so Prisma reconnects using the pool.
This usually stabilizes the database immediately.
2. SSL mismatch after changing your connection string
You mentioned that the problems started after removing sslmode=require.
If your app or your Prisma client was previously set up expecting SSL, removing it can cause handshake failures like:
could not accept SSL connection: EOF detected
How to fix it
Explicitly disable SSL to avoid mismatched negotiation:
?sslmode=disable
Combined with pgbouncer:
postgresql://postgres:<password>@postgres.railway.internal:5432/railway?pgbouncer=true&sslmode=disable
Then regenerate Prisma:
npx prisma generate
And redeploy.
Additional things to check
Restart your Postgres instance
Railway → Your Postgres Service → Restart
If it was stuck in a crash/recovery loop, this often clears it.
Look for long-running queries or stuck migrations
Run:
railway psql
Then:
SELECT pid, query FROM pg_stat_activity;
Kill anything that’s stuck.
If the issue still persists
If even with pooling + sslmode=disable Postgres keeps restarting, it may point to:
• WAL/redo log corruption
• a partially applied migration
• the instance hitting memory limits
These can make Postgres crash repeatedly.
The connection string that fixes 90% of these cases
Try this first:
postgresql://postgres:<password>@postgres.railway.internal:5432/railway?pgbouncer=true&sslmode=disable
Then redeploy your backend.
3 Replies
3 months ago
Hey there! We've found the following might help you get unblocked faster:
🧵 Posgresql cant connect without sslmode=disable inside railway
🧵 Failed to prune sessions: Error: self-signed certificate in certificate chain
If you find the answer from one of these, please let us know by solving the thread!
3 months ago
This thread has been marked as public for community involvement, as it does not contain any sensitive or personal information. Any further activity in this thread will be visible to everyone.
Status changed to Open ray-chen • 3 months ago
3 months ago
Hi! Sorry you’re dealing with this, the issues you’re describing usually come down to two common causes on Railway:
1. Too many database connections
Railway Postgres has a relatively low connection limit. When your app exceeds it, you’ll see errors like:
• connection reset by peer
• Prisma timeouts
• 502 errors from your backend
• Postgres restarting or going into recovery
Prisma, in particular, opens multiple connections per instance. So if you have:
• multiple backend replicas
• a serverless frontend hitting your API frequently
• long-lived Prisma clients
…your database can get overwhelmed pretty quickly.
How to fix it
Use Prisma’s connection pooling by adding ?pgbouncer=true to your Postgres URL — even when using internal connections:
postgresql://postgres:<password>@postgres.railway.internal:5432/railway?pgbouncer=true
After updating your URL, redeploy your backend so Prisma reconnects using the pool.
This usually stabilizes the database immediately.
2. SSL mismatch after changing your connection string
You mentioned that the problems started after removing sslmode=require.
If your app or your Prisma client was previously set up expecting SSL, removing it can cause handshake failures like:
could not accept SSL connection: EOF detected
How to fix it
Explicitly disable SSL to avoid mismatched negotiation:
?sslmode=disable
Combined with pgbouncer:
postgresql://postgres:<password>@postgres.railway.internal:5432/railway?pgbouncer=true&sslmode=disable
Then regenerate Prisma:
npx prisma generate
And redeploy.
Additional things to check
Restart your Postgres instance
Railway → Your Postgres Service → Restart
If it was stuck in a crash/recovery loop, this often clears it.
Look for long-running queries or stuck migrations
Run:
railway psql
Then:
SELECT pid, query FROM pg_stat_activity;
Kill anything that’s stuck.
If the issue still persists
If even with pooling + sslmode=disable Postgres keeps restarting, it may point to:
• WAL/redo log corruption
• a partially applied migration
• the instance hitting memory limits
These can make Postgres crash repeatedly.
The connection string that fixes 90% of these cases
Try this first:
postgresql://postgres:<password>@postgres.railway.internal:5432/railway?pgbouncer=true&sslmode=disable
Then redeploy your backend.
devmuktary
Hi! Sorry you’re dealing with this, the issues you’re describing usually come down to two common causes on Railway:1. Too many database connectionsRailway Postgres has a relatively low connection limit. When your app exceeds it, you’ll see errors like:• connection reset by peer• Prisma timeouts• 502 errors from your backend• Postgres restarting or going into recoveryPrisma, in particular, opens multiple connections per instance. So if you have:• multiple backend replicas• a serverless frontend hitting your API frequently• long-lived Prisma clients…your database can get overwhelmed pretty quickly.How to fix itUse Prisma’s connection pooling by adding ?pgbouncer=true to your Postgres URL — even when using internal connections:postgresql://postgres:<password>@postgres.railway.internal:5432/railway?pgbouncer=trueAfter updating your URL, redeploy your backend so Prisma reconnects using the pool.This usually stabilizes the database immediately.2. SSL mismatch after changing your connection stringYou mentioned that the problems started after removing sslmode=require.If your app or your Prisma client was previously set up expecting SSL, removing it can cause handshake failures like:could not accept SSL connection: EOF detectedHow to fix itExplicitly disable SSL to avoid mismatched negotiation:?sslmode=disableCombined with pgbouncer:postgresql://postgres:<password>@postgres.railway.internal:5432/railway?pgbouncer=true&sslmode=disableThen regenerate Prisma:npx prisma generateAnd redeploy.Additional things to checkRestart your Postgres instanceRailway → Your Postgres Service → RestartIf it was stuck in a crash/recovery loop, this often clears it.Look for long-running queries or stuck migrationsRun:railway psqlThen:SELECT pid, query FROM pg_stat_activity;Kill anything that’s stuck.If the issue still persistsIf even with pooling + sslmode=disable Postgres keeps restarting, it may point to:• WAL/redo log corruption• a partially applied migration• the instance hitting memory limitsThese can make Postgres crash repeatedly.The connection string that fixes 90% of these casesTry this first:postgresql://postgres:<password>@postgres.railway.internal:5432/railway?pgbouncer=true&sslmode=disableThen redeploy your backend.
3 months ago
It is working now. Thank you!
Status changed to Solved noahd • 3 months ago