One Postgres, Two Lives: Neon in Production, Docker in Local Dev

A managed serverless Postgres and a container running on a laptop are different databases with the same wire protocol. Both matter for different reasons, and dev-hub actually ended up using Neon in both places rather than keeping the split clean — which is worth being honest about.

What Neon is for

Neon separates storage from compute and scales the compute side to zero when nothing's querying it, which fits a low-traffic personal site's usage pattern far better than a fixed-size always-on instance. Branching is the feature that matters most for workflow: a Neon branch is a copy-on-write clone of the database, created in seconds, that can back a preview deploy or a one-off experiment without touching production data.

What Docker Compose is for

The original intent — "PostgreSQL + app running locally with one command" — is about removing setup friction and giving local development a disposable, resettable database that doesn't care what happens to it. docker compose down -v and start over costs nothing.

Where dev-hub actually landed

In practice, DATABASE_URL in local .env points at the same Neon instance the live site uses — there's no separate local Postgres container wired up day to day. For a single-author personal site, running one database and being careful (drafts stay unpublished, test data gets deleted after a manual check) has been simpler than maintaining two schemas in sync. That's a reasonable trade-off at this scale; it stops being reasonable the moment there's a second contributor or a CI pipeline that needs to write test data without any chance of touching real rows — at which point Neon branching, not a local container, is the more likely next step, since a branch can be provisioned per pull request and thrown away after.