Databases, Regions and Scaling

Database options

• Railway: add Postgres to the project; use private networking from services in the same project.
• Fly.io: use Fly's managed Postgres offering or an external managed provider (Neon, Supabase, RDS). Check current options in Fly's docs; running Postgres yourself on machines means you own backups and failover.

Whichever you choose: confirm backups, test a restore, and keep the database close to the app.

Regions and latency

A request from your app to a database across an ocean adds tens to hundreds of milliseconds per query, and pages run many queries. Rules:

• Keep app and primary database in the same region.
• Multi-region app instances help only for cached or read-only content, or with read replicas near each region and writes sent to the primary.

Scaling on Fly.io

fly scale count 2                     # two machines in the primary region
fly scale count 3 --region lhr,ams    # spread across regions
fly scale vm shared-cpu-2x --memory 1024

Scaling on Railway

Increase resources for a service and add replicas in the service settings; replicas share the load behind Railway's routing.

Stateless requirements

Before running more than one instance, move sessions to signed cookies or Redis, uploads to object storage, scheduled jobs to a single worker or cron service, and rate limits to Redis. Otherwise behaviour becomes inconsistent between instances.

Exercise

Run two instances of your app, prove sessions and rate limits work across both (Redis), and measure page time with the database in the same region versus a distant one.

Check yourself

• Why keep the app and database in the same region?
• When do multi-region instances actually help?
• What must change before scaling to several instances?