its a timing issue, your app connects before postgres is ready. add these to application.properties:

spring.datasource.hikari.connection-timeout=30000
spring.datasource.hikari.initialization-fail-timeout=-1

this makes hikari wait longer and keep retrying on startup instead of failing instantly

That doesn’t fully make sense to me.
This also happens when I deploy a new version of my service while Postgres itself hasn’t been restarted or changed at all.
In that case Postgres should already be up and accepting connections, so a simple “DB not ready yet” timing issue seems unlikely to be the root cause.

good point. youre right, if postgres is already up the hikari fix helps with retries but doesnt address why its failing. few other common causes:

connection pool issue ! your old deployment might not be releasing connections fast enough before the new one tries to connect. postgres hits max connections. check your hikari pool settings:

spring.datasource.hikari.maximum-pool-size=5
spring.datasource.hikari.minimum-idle=2

use internal url ! make sure youre using the private/internal connection url (has railway.internal in it) not the public proxy url. internal networking is way more stable

check postgres logs ! look at your postgres logs right when the backend deploys to see if you hit max connections or if postgres is actually cycling/restarting even though you didnt trigger it

the retry logic still helps but yeah we need to figure out the root cause too

hope this help you

I checked the Postgres logs during a failed deploy.
The only log line around that time is:

LOG: database system is ready to accept connections

No errors, restarts, or max connection warnings were logged.

I’m using the internal DB URL. I’ve now limited the Hikari pool size to reduce connection spikes during redeploys

youre right postgres is already up. the real issue is during the deployment transition ,when railway swaps from old to new deployment, theres a brief window where networking is being reconfigured.

what's actually happening is that old deployment still has connections open and new deployment starts and tries to connect then during that overlap, railways internal network routing between your new container and postgres isnt fully stable yet, so connections get reset even though postgres itself is running fine

the hikari fix still works because it makes your app retry during that transition window instead of failing instantly. the person in the dec 2025 thread with your exact issue confirmed it worked - "zero failed deployments" after adding those configs.

alternative if you dont trust the retry approach add a healthcheck to your backend service that railway waits for before switching traffic. this gives more time for networking to stabilize

I appreciate your help. I’ll mark this answer as the solution and open a new thread if needed.