Local, Staging, Production: Different but the Same

~12 min · apps, environments

Level 0Schema Seedling

0 XP0/86 lessons0/10 achievements

0/120 XP to next level120 XP to go0% complete

The three-environment story

Most teams run three Postgres environments: local (developer machines), staging (a hosted clone for integration), production (the real one). The schema must be identical across all three; the data should not be.

What changes per environment

Connection string (different host/credentials).
Data (seed in dev, realistic-but-fake in staging, real in prod).
Resource size (1GB on dev, 4GB on staging, whatever prod needs).
Backup cadence (none on dev, hourly on staging, continuous on prod).
SSL (off on local, required on staging/prod).

What must NOT change

The schema (managed by migrations — same migrations, same order, same final state).
The Postgres major version. Test on the same major you run in prod. Differences in planner, JSON path, generated columns can bite.
The set of installed extensions.

Code

Environment-specific config·bash

# .env.local
DATABASE_URL=postgresql://app:dev@localhost:5432/myapp_dev

# .env.staging (in CI / hosting platform)
DATABASE_URL=postgresql://app:****@staging-db.example.com/myapp?sslmode=require

# .env.production
DATABASE_URL=postgresql://app:****@prod-db.example.com/myapp?sslmode=require

Spin up local Postgres·bash

# Native install (preferred — no docker overhead)
brew install postgresql@17
brew services start postgresql@17
createdb myapp_dev

# Or via your cloud provider's free tier:
# Supabase, Neon, Railway, Render — all have free Postgres

External links

Twelve-Factor App — Backing Services

Exercise

Audit your project: are local, staging, and prod all on the same Postgres major version? Same set of extensions? Same migration history? List any drifts and plan how to align them.