The same Postgres you rent from a managed database service, at a recurring premium, will run on your own servers on fast local NVMe, for the cost of hardware you already pay for. That is the whole pitch for owning your database. The catch is that owning it means owning backups, upgrades, and failover too. This page is the map: the tradeoff first, then a signpost to every recipe that does the actual work.

## Run it yourself, or keep renting

Owning a database is real operational work, so be honest about which side of this you fall on.

- **Run it yourself** when you want the cost saving and the control, and you are willing to own the operations. A good operator scripts the hard parts, which makes that much less painful.
- **Keep it managed** when the database is small, the team is tiny, and the premium buys you not having to think about it.

It does not have to be all-or-nothing.

> [!TIP]
> Run your dev and staging databases on the cluster and keep production managed while you build confidence. Once your team trusts the failover and the restores on the databases that do not page anyone, move production over. You get the cost saving early and the risk late.

## Use an operator, not a raw StatefulSet

You _can_ run Postgres as a [plain StatefulSet](/docs/hetzner/apalla/workloads/stateful/run-a-statefulset-with-storage), and for a throwaway instance that is fine. For anything that holds data you care about, use an operator. It encodes the operational knowledge (failover, replication, backups, point-in-time recovery) so you are not scripting it during an outage.

**CloudNativePG** is the usual choice for PostgreSQL. It runs a replicated Postgres with automatic failover and continuous backup to object storage, all expressed as ordinary Kubernetes objects. Other databases have their own operators: MySQL, MongoDB, and Redis each ship one.

## Where the detailed guides live

Each of these is a full recipe. Start with the one that matches what you are doing.

- [Run a StatefulSet with storage](/docs/hetzner/apalla/workloads/stateful/run-a-statefulset-with-storage)
- [Survive node replacement](/docs/hetzner/apalla/workloads/stateful/stateful-placement-and-node-replacement)
- [Disaster recovery](/docs/hetzner/apalla/storage/backup/disaster-recovery-stateful)
- [Stay up through upgrades](/docs/hetzner/apalla/clusters/availability/keep-databases-available)

## Storage, placement, and latency

Three decisions carry over from the pages above, so these are pointers, not a re-explanation. Storage class and the one-per-node placement pattern are covered in [Run a StatefulSet with storage](/docs/hetzner/apalla/workloads/stateful/run-a-statefulset-with-storage) and [Survive node replacement](/docs/hetzner/apalla/workloads/stateful/stateful-placement-and-node-replacement).

Latency is the one worth naming here. On a multi-socket bare-metal server, [NUMA alignment](/docs/hetzner/apalla/workloads/specialized/run-numa-aligned-workloads) pins the database's CPUs and memory to a single socket, cutting the cost of memory access. For a latency-sensitive database on the right hardware, that is a real, measurable win.