Docs / Grow in stages

Stage 4: All on Kubernetes

Exploring This stage is being evaluated. The approach may change a lot, or parts of it may be dropped. Treat this page as current thinking, not a plan.

In stage 4, the data services that stayed on virtual machines in stage 3 move into the Kubernetes cluster too: PostgreSQL, RustFS and, if used, Valkey. It is meant for larger platforms where running data services outside the cluster has become the bottleneck.

Most organizations don’t need it

Be honest about why you want stage 4. Running databases in Kubernetes is well understood today, but it asks more of your team: storage that survives node failures, operators you have to upgrade, and recovery procedures that depend on the cluster being healthy.

Stage 3, with data on dedicated VMs, is simpler to reason about and easier to recover. Consider stage 4 only when the VM approach is genuinely holding you back, for example:

• Many teams each need their own PostgreSQL clusters, and creating them through Ansible merge requests has become slow.
• You run enough database clusters that consistent, declarative management beats per-VM roles.
• You are running GPU workloads that need data close to the compute and scheduled alongside it.

If none of these apply, staying at stage 3 is the right answer.

PostgreSQL with an operator

The option under evaluation is CloudNativePG, a Kubernetes operator for PostgreSQL. It manages replicas and failover inside the cluster, can back up to S3-compatible storage, and can bootstrap a new cluster from an existing one.

That last part is why the earlier stages send backups to S3 from day one. The plan is for a stage 4 cluster to be restored from the same backups stage 1 has been taking, or to stream from the existing PostgreSQL VMs before a cutover. How well this works with backups taken by pgBackRest rather than by the operator itself is one of the things we are checking. A logical migration or a replica-based cutover may turn out to be the cleaner route.

Object storage

RustFS would run as a StatefulSet on dedicated storage nodes, with local disks reserved for it. Because the design only uses the standard S3 API, applications shouldn’t notice the move beyond an endpoint change. RustFS is still young, so its maturity will be reviewed again before this stage is built; MinIO, Garage, SeaweedFS or Ceph RGW remain possible substitutes. See RustFS.

Storage options

Data services in Kubernetes need persistent volumes that survive a node failure. Two options are being evaluated:

A third route is to give databases local disks and rely on PostgreSQL replication instead of replicated volumes. That is often faster and is still on the table.

GPU workloads

For organizations running machine learning or other GPU work on their own hardware, the NVIDIA GPU operator installs drivers and the device plugin so Kubernetes can schedule pods onto GPU nodes. This is planned for evaluation alongside the rest of stage 4, but GPU nodes could also be added to a stage 3 cluster on their own if that is all you need.

What would carry over

The repository, the change flow, the routine checks and the backups all stay the same. Ansible would still manage the operating system and Kubernetes itself; only the data services would move from Ansible roles to manifests under k8s/. See Moving between stages and Roadmap and status.

Last updated 25 October 2026 · Questions or corrections: sales@infratractor.com