Running Postgres on your own NVMe-backed servers costs only the hardware you already own, instead of the recurring premium a managed service charges. The catch is that you also take on backups, upgrades, and failover, and this page maps that tradeoff before guiding you through the setup.

## Run it yourself, or keep renting

Self-hosting a database is ongoing operational work. Ensure your team can handle backups, upgrades, and failover before committing to it.

- **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 reduces the effort your team has to put overall.
- **Keep it managed** when the database is small, the team is tiny, and the premium allows you to not worry about the database.

> [!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 non-production databases, 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 staging instance that is fine. For anything that holds production data, 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 section below is a complete guide. Start with the one that matches your task.

- [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

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).

As for latency, a multi-socket bare-metal server splits its memory across sockets, and a process reaching memory attached to another socket pays an extra hop. [NUMA alignment](/docs/hetzner/apalla/workloads/specialized/run-numa-aligned-workloads) pins the database’s CPUs and memory to one socket so every memory access stays local. For a latency-sensitive database on suitable hardware, this is a measurable improvement.