5 days ago
My web service connects to Postgres over postgres.railway.internal:5432. A bare SELECT 1 on a warm pooled connection consistently takes ~170ms. I'd expect close to 1ms for private networking inside one project.
Measured from inside the running container at boot, five consecutive round trips:
14 Aug: 176 / 176 / 176 / 175 / 176 ms
16 Aug: 170 / 170 / 171 / 170 / 170 ms
Across 350 sequential idempotent DDL statements (CREATE TABLE IF NOT EXISTS, ALTER TABLE ... ADD COLUMN IF NOT EXISTS) during startup: p50 171ms, p90 173ms, total 48.5s. The identical statements against a local Postgres 18 complete in 32ms total (p50 0ms), so the database is doing essentially no work — the time is entirely the network path.
What I've already ruled out:
Configuration — DATABASE_URL is postgres.railway.internal:5432; the log confirms the connected host at runtime. DATABASE_PUBLIC_URL is set separately for failover and is not in use.
Lock or catalogue contention — p90 (173ms) is within 2ms of p50, so there is no spread; it's a flat per-round-trip cost.
Connection churn — five sequential queries on one pooled client, all identical. Not TLS handshakes.
Region mismatch — both services report asia-southeast1.
One possible lead: railway status --json shows every service instance with region: null, plus deprecatedRegions: ["asia-southeast1"] and replacementRegion: "asia-southeast1-eqsg3a". Is it possible these two services are physically placed in different clusters — one on the deprecated asia-southeast1 and one on asia-southeast1-eqsg3a — so "private" traffic is routing between them?
Questions:
Is ~170ms expected for intra-project private networking in asia-southeast1, or is this a misconfiguration/placement issue?
Can you confirm where these two service containers are actually placed?
If it's a placement split, what's the correct way to move them onto the same cluster — and is there downtime?
This affects every request the product makes, not just startup. Happy to run any diagnostic from inside the container.
4 Replies
5 days ago
We've looked into this from our side and haven't found anything on the Railway platform that explains what you're seeing, so working it out means digging into your specific setup.
That's exactly what the Railway community is good at, so we'd like to open your thread as a community bounty. Railway pays a bounty to the community member who solves it, and threads like this usually get picked up quickly.
Opening it makes this entire thread public, including everything already posted. Nothing becomes public until you decide. Use the buttons below.
- Open to the community - Before you click, take a moment to edit or remove anything you'd rather not share. The thread becomes publicly visible right away.
- Keep it private and close the thread - Nothing becomes public and the thread closes.
Status changed to Awaiting User Response Railway • 5 days ago
5 days ago
This thread has been opened as a public bounty so the community can help solve it. The thread and any further activity are now visible to everyone.
Status changed to Open Railway • 5 days ago
5 days ago
I might suggest moving Postgres into the same region. It is currently deployed to US-West, while the other services are all deployed to Asia.
Status changed to Awaiting User Response Railway • 5 days ago
brody
I might suggest moving Postgres into the same region. It is currently deployed to US-West, while the other services are all deployed to Asia.
5 days ago
Follow-up with measurements — this looks like service placement, not private-network routing.
I compared both paths to the same database from inside the running container:
private postgres.railway.internal:5432 178/178/178/178/178 ms
public switchback.proxy.rlwy.net:25425 1245/175/175/175/178 ms (first = TCP+TLS setup)
The two paths are the same speed. That rules out the private-network routing problem I originally suspected — if private networking were misrouting, the public path would differ.
Triangulating from a second origin: from Sydney, minimum TCP RTT to the proxy is 166ms over 12 samples. From the app container in asia-southeast1 it's 175ms. Both are consistent with the Postgres being in a US-West region. If it were co-located in asia-southeast1, the app should see ~1–5ms and Sydney ~95ms; neither does.
So my question narrows to placement:
Can you confirm the physical region of service Postgres (e6c4f24d-db41-4afc-8591-b36ea8f9b08b)? The project metadata reports region: null inheriting asia-southeast1, but the measurements don't support that.
If it is in a different region from blinkered-classroom (3d38f40a-6969-4b7b-80f4-8b2bebeee4ad), what's the supported way to move it into asia-southeast1, and what downtime should I plan for?
Is this related to the asia-southeast1 → asia-southeast1-eqsg3a migration showing in deprecatedRegions?
Status changed to Awaiting Railway Response Railway • 5 days ago
jf1991999
Follow-up with measurements — this looks like service placement, not private-network routing. I compared both paths to the same database from inside the running container: private postgres.railway.internal:5432 178/178/178/178/178 ms public switchback.proxy.rlwy.net:25425 1245/175/175/175/178 ms (first = TCP+TLS setup) The two paths are the same speed. That rules out the private-network routing problem I originally suspected — if private networking were misrouting, the public path would differ. Triangulating from a second origin: from Sydney, minimum TCP RTT to the proxy is 166ms over 12 samples. From the app container in asia-southeast1 it's 175ms. Both are consistent with the Postgres being in a US-West region. If it were co-located in asia-southeast1, the app should see ~1–5ms and Sydney ~95ms; neither does. So my question narrows to placement: Can you confirm the physical region of service Postgres (e6c4f24d-db41-4afc-8591-b36ea8f9b08b)? The project metadata reports region: null inheriting asia-southeast1, but the measurements don't support that. If it is in a different region from blinkered-classroom (3d38f40a-6969-4b7b-80f4-8b2bebeee4ad), what's the supported way to move it into asia-southeast1, and what downtime should I plan for? Is this related to the asia-southeast1 → asia-southeast1-eqsg3a migration showing in deprecatedRegions?
5 days ago
Sorry posted before seeing your message. That is clearly the issue. I ma not sure why this wasn't in the same location. Will fix.