2 months ago
Environment
PostGIS: Docker image deployed as a service on Railway
Backend: NestJS (Node 20) with Prisma, deployed as a separate service
Connection: via
DATABASE_URL
provided by Railway, using default Prisma pool settings
Symptom
My backend intermittently crashes with TCP resets, then recovers after a restart. In the logs I see:
# PostGIS container logs
2025-06-24 17:23:58 PostGIS LOG: could not receive data from client: Connection reset by peer
# NestJS backend logs
Error: read ECONNRESET
at TCP.onStreamRead (node:internal/stream_base_commons:216:20)
errno: -104,
code: 'ECONNRESET',
syscall: 'read'
ELIFECYCLE Command failed with exit code 1
When this happens, my Prisma/pg pool attempts to reuse a connection that’s been closed by the server (or by Railway’s network layer), triggering ECONNRESET
. Restarting the backend temporarily fixes it, but the resets resume unpredictably.
Request
Could you help me identify what on Railway might be closing idle TCP connections? Is there a recommended pool configuration, network timeout setting, or side-car (PgBouncer) integration I should use to maintain stable long-lived connections between my NestJS/Prisma service and the PostGIS database?
Thank you!
5 Replies
2 months ago
Hi there,
How many connections do you presume to be making to the database? And has this increased recently?
If so, you can consider putting pgbouncer in front of your database.
Regards,
Christian
Status changed to Awaiting User Response Railway • about 2 months ago
2 months ago
There's a new bug that appeared overnight. The PostGIS container decided to redeploy overnight and it failed. No manual action was taken, but it appears to be having trouble migrating the volume.
This is starting to cause a lot of bugs on one of the most critical services. I seriously wonder if Railway is a stable solution.
Attachments
Status changed to Awaiting Railway Response Railway • about 2 months ago
2 months ago
Heya, could you elaborate on issues this has caused ? while your migration failed, your database remains online and operational.
It's likely there was a blip during the migration failure which caused the error you sent.
Status changed to Awaiting User Response Railway • about 2 months ago
itsrems
Heya, could you elaborate on issues this has caused ? while your migration failed, your database remains online and operational.It's likely there was a blip during the migration failure which caused the error you sent.
2 months ago
Certainly my database is still operational but it is still worrying that deployments are happening without us even being at the initiative and that you cannot find it?
Status changed to Awaiting Railway Response Railway • about 2 months ago
2 months ago
Hello Alex,
First off, our transition to Railway Metal has been well communicated ahead of time via our documentation pages and our email communications.
With that said, the ECONRESET errors that you are reporting are unlikely to do with Railway provided infrastructure. I see that you have two up
redpployments for your DB and that would be likely to cause issues with your deployments.
There is not much else we can provide for you here as the DBs on Railway are not managed and could be affected by a variety of factors such as connections and load.
Status changed to Awaiting User Response Railway • about 2 months ago
9 days ago
This thread has been marked as solved automatically due to a lack of recent activity. Please re-open this thread or create a new one if you require further assistance. Thank you!
Status changed to Solved Railway • 9 days ago