1 Why a dedicated database machine
Instead of tucking a database inside each application's own server, we run it on its own machine. That separation buys us a few things that matter as we grow:
- Isolation. A traffic spike, deploy, or bug in one app can't starve the database of memory or CPU — and a database problem can't take an unrelated app down with it.
- One thing to secure. Instead of a database exposed on every app server, there's a single, tightly firewalled machine to lock down and monitor.
- Shared, not duplicated. Multiple internal services can use the same well-tuned Postgres install instead of every project reinventing its own data layer.
- Room to grow independently. We can resize, back up, patch, or eventually replicate the database on its own schedule, without touching application code.
2 Why Postgres
PostgreSQL is the default choice for internal, production-grade data for reasons that go beyond "it's popular":
- Correctness first. Postgres is fully transactional (ACID) — it won't quietly lose or corrupt data, even under concurrent writes or a crash mid-operation.
- Grows with the use case. Relational tables today, JSON documents, full-text search, or geospatial data tomorrow — all in the same engine, without bolting on another database later.
- Free and open. No per-seat licensing, no vendor lock-in, and a massive ecosystem of tooling, drivers, and hosting options if we ever need to move it.
- Battle-tested. Decades of production use across companies of every size — the rough edges have already been found and fixed by someone else.
- Ready for AI workloads. Via the
pgvectorextension, Postgres stores and searches vector embeddings natively — so semantic search, recommendations, and RAG features can live right next to the rest of our data instead of needing a separate vector database.
3 A private tunnel in, not an open door
The database doesn't listen to "the internet" the way a normal website does. It only accepts connections from machines we've explicitly approved in advance — every other computer on the planet is refused a connection before it ever reaches the database software.
Think of it like a private tunnel with a guest list at the door: only pre-approved office and service IP addresses are allowed to even knock, and every connection still has to prove itself with a password on top of that. It's the same instinct behind a VPN — restrict who can reach the resource at all — applied directly at the network's front gate.
The connection itself is encrypted end-to-end with TLS (the same kind of certificate that secures this page), so credentials and query results can't be read in transit either. Getting in requires both halves at once: the pinhole (being on an approved IP) and the key (a valid password) — one without the other gets you nowhere. Formalizing this into a full VPN tunnel is the natural next step as more services connect.