Per-replica connection-pool sizing versus Railway PostgreSQL max_connections

Answer to the Core Questions

1. Maximum safe pool size per replica

Given a Railway PostgreSQL instance with max_connections = M and a target of R application replicas, a conservative per‑replica pool limit is:

pool_max = ⌊(M - H) / R⌋

where H is a small overhead reserve for administrative tools, monitoring, and any non‑replica services that will also connect to the database. A typical value for H is 5–10 connections, but you should adjust it to your own usage.

Example: M = 100, R = 4, H = 5 → pool_max = ⌊(100-5)/4⌋ = 23 connections per replica.

2. Impact of request distribution on connection churn

• Even distribution: Each replica receives roughly the same number of concurrent requests. The total number of open connections is approximately R × pool_max, which stays within M if the formula above is respected.
• Burst traffic: A sudden spike may cause several replicas to open connections near pool_max simultaneously. If the sum of those temporary spikes exceeds M, the database will reject new connections, leading to queueing or failures in the application layer.
• Uneven load: If the load balancer routes a disproportionate share of traffic to one replica, that replica can reach its local pool ceiling while others remain idle, causing local queueing even when the global pool is underutilised.

3. Dedicated sidecar vs. application‑level tuning

• When R × pool_max < M and traffic patterns are predictable, tuning the driver’s pool size (max pool size, idle timeout, max wait time) is usually sufficient and keeps the architecture simple.
• If you need to scale to many replicas or expect frequent bursts, a lightweight connection‑pooling sidecar such as PgBouncer in transaction mode can reduce the number of actual database connections. It introduces an extra hop inside Railway’s private network but can smooth spikes and free up M for other services.
• Choose a sidecar only if you observe that the per‑replica pool calculation is too restrictive for your performance goals or if you have background workers that also consume a significant share of M.

Assumptions & Uncertainty

The formula assumes:

• All replicas run the same application code and share the same driver configuration.
• Traffic is evenly distributed by the load balancer.
• No other services (e.g., cron jobs, monitoring agents) consume more than the reserved H connections.

If any of these assumptions do not hold, the calculated pool_max may be too optimistic.

Verification Steps

1. Check the hard limit in PostgreSQL:

   SELECT setting::int FROM pg_settings WHERE name = 'max_connections';

2. Verify the current number of application replicas in the Railway dashboard or by inspecting the deployment metadata.
3. Monitor pg_stat_activity during peak periods to see the actual number of active connections per host:

   SELECT client_addr, COUNT(*) AS active
   FROM pg_stat_activity
   GROUP BY client_addr;
   

4. Observe application metrics for pool wait times to detect queueing caused by hitting the per‑replica limit.

Missing Diagnostic Detail

To refine the calculation, please confirm whether you have background workers, scheduled jobs, or other services that also connect to the same PostgreSQL instance. If so, we need to reserve a portion of M for them, which will reduce the per‑replica pool size.