Thanks for the detailed report, we'll track the issue as a data point for the networking team. One thing worth checking: if your environment was created before October 16, 2025, it uses IPv6-only private networking, which can compound this issue. Creating a new environment would give you dual-stack (IPv4/IPv6) private networking and may reduce the latency.

Hi, sorry for the no reply I didn't see a notification for this response. It was created in 2026 so no concern about IPv6 only networking. I'm actually also experiencing this with another service besides PG Bouncer. I have a Go service running in a container that was connecting to the database URL via internal networking, and was incurring a 100-135ms penalty per query for cross-region and several ms per query for in-region. Now that I'm using external networking I see a significantly reduced penalty for cross-region (upwards of 80ms from limited data collection), and a slightly reduced penalty for same-region as well.

I would really love to be able to provide any more information for debugging or identifying the issue. I am happy to collect any data internal to our services to support identifying this issue.

Thanks again for your time and support!

The 2026 environment rules out the legacy IPv6-only explanation. The next useful step is to determine whether the extra time is paid once per connection or on every round trip, and whether it follows one private address family. That turns this from a general latency report into a route Railway can trace.

Run the same matrix from one fixed application replica against the same Postgres primary. Keep credentials in environment variables and do not paste connection strings:

1. Record the actual placement at runtime from both services, not only the configured region: RAILWAY_REPLICA_REGION, RAILWAY_REPLICA_ID and RAILWAY_DEPLOYMENT_ID. Railway exposes these specifically for per-replica correlation. Confirm the PgBouncer/Go client and Postgres primary report the expected regions.

2. Resolve the private hostname once with getent ahosts <postgres>.railway.internal. In a new 2026 environment it can return both IPv4 and IPv6. Test each returned address separately only for diagnosis; with libpq you can set host=<private-hostname> plus hostaddr=<resolved-address> so hostname/TLS behavior is preserved while selecting the route. Do not hard-code a private address as the production fix because it can change.

3. Split connection setup from query RTT. With pgbench available, run a persistent-session read-only test and then the same test with -C (new connection per transaction), first over private networking and then over the TCP proxy:

   
   pgbench "$PRIVATE_DATABASE_URL" -S -T 60 -P 5 -c 1 -j 1
   
   pgbench "$PRIVATE_DATABASE_URL" -S -T 60 -P 5 -c 1 -j 1 -C
   
   pgbench "$PUBLIC_DATABASE_URL"  -S -T 60 -P 5 -c 1 -j 1
   
   pgbench "$PUBLIC_DATABASE_URL"  -S -T 60 -P 5 -c 1 -j 1 -C
   

   Use sealed variables and redact command output that contains endpoints. If only -C is slow, the penalty is DNS/address selection, TCP/TLS or authentication/pool setup. If a single persistent session still adds ~100 ms to every SELECT 1, the private data path itself is adding RTT.

4. During the persistent test, capture kernel TCP measurements for the established database socket with ss -tin (redact credentials; IP/RTT/cwnd/retransmit data is enough). Repeat for private IPv4, private IPv6 and the public proxy. Also record PgBouncer SHOW STATS; / SHOW POOLS; before and after so queue wait or pool saturation is not mistaken for network RTT.

5. Run the matrix once in-region and once cross-region with the same client image, pool settings and query count. Report median/p95, connection rate, TCP RTT/retransmits, selected address family and both replica IDs. A slow private family with the other private family fast identifies a dual-stack/WireGuard path; both private families slow on a persistent session while the public proxy is fast identifies the private-mesh route; only new connections slow identifies client/pool setup.

Railway currently documents private service traffic as an encrypted WireGuard mesh scoped to one project/environment and recommends it as the lower-latency, no-egress path. Therefore the public TCP proxy should not be the permanent workaround if this controlled persistent-session test proves the opposite. Send Railway the paired UTC window, deployment/replica IDs, actual source/destination regions, private address family, TCP RTT/retransmits and pgbench summaries. That is sufficient for the networking team to locate the tunnel/route without exposing database credentials or application data.

Official references:

• https://docs.railway.com/private-networking
• https://docs.railway.com/variables/reference
• https://docs.railway.com/deployments/troubleshooting/slow-deployments
• https://docs.railway.com/overview/best-practices