Run databases on the cluster
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 , 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.
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 and Survive node replacement .
Latency is the one worth naming here. On a multi-socket bare-metal server, NUMA alignment 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.
Keep stateful pods safe across node replacement
How to place stateful replicas so a Syself Autopilot node replacement rebuilds one member at a time and never costs you quorum or local data.
Run a Job
Run a task that runs to completion once and reports success or failure, and design it to survive being evicted mid-run.