Intermittent ECONNRESET / “Connection reset by peer” between NestJS (Prisma) and PostGIS on Railway

alexrastello
PRO

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!

Solved

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


alexrastello
PRO

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.

alexrastello
PRO

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


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


Railway
BOT

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