Too many simultaneous connections? Maybe you can use a connection pool.

Further to joancruceira's point, do you have a lot of traffic going through production? Does it seem to block connections after x amount of requests to access data? Have you manually configured concurrent connections? It does sound like you're hitting a concurrency issue, in which case a connection pool would be the ideal solution.

Out of interest, what database engine are you using?

Append a keepalive flag to your database connection string (e.g., ?keepalive=true). If your API utilizes a Node.js-based headless CMS or backend (like Strapi using Knex.js), ensure your connection pool configuration is set to min: 0. This forces the pool to release completely idle connections rather than holding onto them until the PaaS network drops them.

Also check your Railway database metrics for connection counts. Ensure your API's database driver (or ORM) is properly pooling connections. If you are hitting Railway's native PostgreSQL limits, you may need to enable PgBouncer (which Railway supports natively) to handle connection multiplexing, and adjust your environment variables to route traffic through the PgBouncer port.

This sounds more like a connection lifecycle / pooling issue than PostgreSQL randomly going down.

A few things I’d check first:

1. Compare production vs staging env vars

   Make sure production is not using a different DATABASE_URL, pool size, SSL config, or connection timeout settings.

2. Check connection counts in Railway metrics

   If production has more traffic, you may be exhausting available Postgres connections. In that case, use a proper connection pool or Railway PgBouncer.

3. Review your API’s DB client setup

   If you are using Node.js with Prisma, Knex, Sequelize, TypeORM, Strapi, etc., make sure you are not creating a new database client per request. The DB client should usually be initialized once and reused.

4. Add pool / timeout configuration

   Depending on your stack, configure idle timeouts, max pool size, and reconnect behavior. For low traffic apps, stale idle connections can get dropped and the app may not recover unless the DB client reconnects properly.

5. Redeploy/restart only masks the issue

   Since restarting the API fixes it temporarily, the app is probably holding a dead connection or failing to recreate the pool after disconnect.

What stack/ORM are you using in production? Prisma, Knex, Sequelize, TypeORM, Strapi, Django, Laravel, etc.? That would determine the exact fix.

i am fairly new at this , i added PG bouncer but dont know what i am looking for /at ? i have errors, i setup a Postgres Database and used base settings and havent touched anything, the only thing ive done recently is increased my backup frequency and send that backups to Supabase for redunancy , not sure what to look at or troubshoot

Can you share some screenshots of the errors you're getting?

Thanks for the extra context.

If you already added PgBouncer, the next thing I would check is whether your production API is actually using the pooled connection URL, not the original direct Postgres URL.

A few useful things to share here would be:

1. The exact database-related errors from your API logs
2. The PgBouncer errors/logs, if any
3. Your stack/ORM — for example Prisma, Sequelize, Knex, Strapi, Django, Laravel, etc.
4. Whether your production DATABASE_URL now points to PgBouncer or still points directly to Postgres
5. Your backup setup/frequency, especially if the backup job is using the same production database while the app is active

Be careful not to paste the full connection string publicly. Mask the username, password, host, and tokens.

Also, if your app runs migrations, scheduled jobs, or backup/export jobs, those may need to use the direct/unpooled database URL instead of the PgBouncer pooled URL. PgBouncer is usually for normal application traffic, while some long-running or connection-sensitive operations can behave differently through a pool.

The backup change is worth checking too. If the backup process is running frequently and creating long-lived or repeated connections without closing them cleanly, it could contribute to connection pressure or dead/stale connections.

I’d start by comparing:

• Production API logs at the time the UI loses data
• Postgres connection count/metrics around the same time
• PgBouncer client/server connection counts
• Backup job timing around the same window

If you can share the exact error text, it’ll be much easier to tell whether this is max connections, stale idle connections, SSL/network timeout, PgBouncer config, or the backup process causing pressure.

this is logs from pgbouncer, where do i find the url for pg bouncer?

Those logs don’t look like PgBouncer errors to me. They look like pgBackRest / WAL archive-push logs from the Postgres backup/PITR process, and the lines shown say the archive push completed successfully.

So this probably isn’t the actual error causing the app to lose database access.

For the PgBouncer URL, check the PgBouncer service in Railway, not the Postgres service:

1. Open your Railway project
2. Click the PgBouncer service
3. Go to Variables
4. Look for DATABASE_URL
5. Use that DATABASE_URL in your production API service

In your API service, your DATABASE_URL should point to PgBouncer, not directly to Postgres.

If Railway lets you reference variables, it would be something like:

DATABASE_URL=${{PgBouncer.DATABASE_URL}}

The exact service name may be different depending on what your PgBouncer service is called.

Also keep a direct/unpooled Postgres URL separately for migrations, backups, or long-running DB jobs. Don’t run migrations/backups through PgBouncer unless you know your ORM/tool supports it.

The logs we still need are the API logs from the exact time the UI loses data, not only the Postgres backup/archive logs.

Specifically, please check/share:

• API service logs when the issue happens
• PgBouncer service logs, if it has its own separate service
• Postgres connection count around that time
• Whether your API DATABASE_URL currently points to PgBouncer or directly to Postgres
• What stack/ORM you use: Prisma, Sequelize, Knex, Strapi, Django, Laravel, etc.

And don’t paste the full connection string publicly. Mask passwords, hostnames, and tokens.