Skip to main content

Run databases on the cluster

Inspect 1.36

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

Storage, placement, and latency

Storage class and the one-per-node placement pattern are covered in and .

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