Hi Railway team,

I'm running a Postgres service (project: postaearn, service ID visible in my dashboard, host hayabusa.proxy.rlwy.net:54412) and seeing consistent, high latency on even the simplest possible query, from multiple independent test angles. I'd like help understanding whether this is expected for my current plan/region, or whether something's wrong on the origin side.

What I've measured, from my own machine (not through any app):

Raw TCP connect to the proxy host: ~0.47s (fast, as expected)

ICMP ping to the same host: 200-345ms, with 46.7% packet loss across a 15-packet sample

A full psql session running nothing but SELECT 1 (connect + auth + query + response): consistently 2-7 seconds across repeated runs, both with SSL enabled and with sslmode=disable (ruling out certificate/TLS negotiation as the cause)

DNS resolution for the proxy hostname: ~180-469ms for a single query (also unusually slow)

Why I don't think this is my network: a plain curl to https://www.google.com from the same machine, at the same time, completed in 0.82s. General connectivity is healthy; the slowness is specific to this Postgres connection.

Why I don't think this is distance/region alone: I ran the identical SELECT 1 test against a completely different provider (Neon) from the same machine and got similarly slow, similarly variable results (multiple seconds, inconsistent across runs) — which suggests something in common between these tests (possibly my own path to US-hosted database infrastructure generally, or something else) rather than an issue specific to Railway's proxy. I'm raising it with you first since you have visibility into origin-side timing that I don't.

What I'd like to know:

Does Railway have server-side timing/logs for connections to this service that could show where the time is actually going (proxy handshake, auth, query execution)?

Is there anything about the public proxy specifically (vs. a hypothetical direct connection) that would explain multi-second overhead on a trivial query?

Is this latency level expected/typical for my current plan, or does it indicate a problem?

Happy to provide more diagnostics (timestamps, additional time psql runs) if useful. This is affecting a production application currently serving real users, so I'd appreciate a look when possible.

Thanks,