9 days ago
Hi Railway Team,
We currently host our application OOZU, a hyperlocal discovery platform, on Railway and are preparing to expand to India*.
Before launching in India, we’d like your guidance on the best deployment architecture and whether our existing Railway plan/infrastructure can support users in both regions efficiently.
Could you please clarify:
- Can we continue using our current Railway plan and deployment for both U.S. and India users, or would you recommend any plan/infrastructure changes?
- Which Railway region would provide the best latency for users in India?
- Does Railway currently support an India or nearby Asia region for our services and database?
- If our backend remains hosted in the U.S., what latency/performance should we expect for users accessing OOZU from India?
- Would you recommend deploying a second backend instance closer to India, while continuing to use the same application/database?
- If we deploy services in multiple regions, what is Railway’s recommended architecture for routing U.S. and India traffic to the nearest region?
- Are there any considerations around our PostgreSQL/database location, cross-region database latency, storage, networking, or egress costs?
- Can the same Railway project/environment support this architecture, or would separate environments/projects be recommended?
- Would our existing pricing plan continue to work, or would multi-region deployment require additional resources or a different plan?
OOZU is location-based and API responsiveness is important because users interact with nearby broadcasts, events, deals, people, messaging, and map/radar data.
Our main goal is to understand whether we can launch in India using our existing setup initially without noticeably affecting speed, and what architecture Railway recommends as Indian usage grows.
Thank you,
OOZU Team
oozu.app
1 Replies
9 days ago
We have no region in India. There are four deploy regions: US West (California), US East (Virginia), EU West (Amsterdam) and Southeast Asia (Singapore). Singapore is the closest one to India. You set the region per service in the service's settings, and you can change it at any time. If a service has a volume attached, changing its region migrates the volume, and the service is down while that runs.
For users in both markets, you can run multi-region replicas of your stateless backend inside the same service, for example one set in the US and one in Singapore. We automatically route public traffic to the nearest region, so you don't need a separate routing layer, project or environment.
Databases usually run in a single region. Replicas that are far from your Postgres primary still wait on the database for every query, so a Singapore replica talking to a US database gains little on query-heavy endpoints. The docs suggest application-level caching, read replicas in other regions for read-heavy traffic, and accepting the latency on writes, which have to go to the primary. Keeping app and database in different regions adds latency to every query, so it pays to design around that.
Changing regions or adding them doesn't need a different plan. Each extra replica is billed for the resources it uses. A Hobby replica can use up to 8 vCPU and 8 GB, and Pro raises that ceiling and allows more replicas.
Status changed to Awaiting User Response Railway • 9 days ago
2 days ago
This thread has been marked as solved automatically due to a lack of recent activity. Please re-open this thread or create a new one if you require further assistance. Thank you!
Status changed to Solved Railway • 2 days ago