41da44a5-bce4-4b1c-b116-24ec2d69337e

Hey, hobby deployments are now restricted to metal so you can't change it to oregon unless you're on pro plan

@Fragly Right now the latancy to hit my railway postgres is very bad. This is a simple select * from users in a table with 1 record. Is it because of the zone difference?

I can't move my database to the same METAL zone either.

Are the services communicating via the private network?

30ms is about expected, that's not "very bad"

The private network should reduce that timing to ~10-20ms

It's very weird. I have a production system right now that uses railway containers to supabase database using the public supabase url, and it's typically 6ms. having more than x4 that from within railway itself is not good. Jake told me I should expect like 1ms internally. 😦

and to confirm I am connecting to Postgres using the postgres.railway.internal:5432/railway connection url variable.

This type of delay is only temporary until Railway metal supports volumes, then your database and web app will be in the same zone again
If this delay is very bad for the service you're running then you're likely supposed to be on pro plan though, hobby plan is only meant for hobby workloads

thank you, I look forward to metal supporting volumes for Postgres! 🙏

Awesome, no problem 🙂

!s