turbopuffer describes operating database clusters it cannot log into

Sources: turbopuffer blog, 2026-08-14, HN discussion
Summary: Tarun Pothulapati describes how turbopuffer runs more than 100 clusters across public SaaS, single-tenant SaaS, and bring-your-own-cloud, holding no credentials into customer accounts by default, so every operation must reach a terminal state without the vendor reaching in. The design uses one Kubernetes custom resource, TurbopufferOperation, to model every operation kind from upgrade to compaction, driven by a local controller reconciliation loop with state durable in the cluster's own etcd, so a control plane outage does not stall a healthy cluster. Each agent polls a central API server backed by PlanetScale MySQL for pending operations and posts status transitions back as an append-only log, made idempotent by naming each custom resource after its operation id, and fleet rollouts proceed in waves with gates that pause on monitor alerts. The post argues against Terraform and GitOps as the control plane, on the grounds that reindexing, WAL compaction, and garbage collection are jobs to be done rather than states to arrive at, and that a repository owned by either party breaks the approval model.
Why it matters: No vendor access into customer infrastructure is a common bring-your-own-cloud constraint, and this post gives a worked design for it rather than a principle.