When to self-host your managed databases: a decision framework

The choice between a public-cloud managed database and running your own is often framed as convenience versus control. For a regulated team the question is narrower: which risks can you accept, and which have to stay inside your own boundary? Here is a decision framework, and where a self-hosted managed platform fits.

Three questions that actually decide it

• Where must the data live? If a regulator requires the data (and the keys) to stay in-country, a public-cloud region may not satisfy it, and the provider’s operators sit outside your control.
• Who can reach it, and can you prove it? In a shared managed service, isolation is the provider’s claim. On your own cluster, the boundary is yours to set and to demonstrate.
• What happens when something breaks? Backups, failover, and version upgrades are the real cost of self-hosting, and the reason teams avoid it.

Residency and jurisdiction

This is the question that most often forces the decision. When the data must remain within a jurisdiction, the model that keeps it there is the one that runs on infrastructure you control. Self-hosting is not about distrust of a cloud provider; it is about keeping the data, the encryption keys, and the legal jurisdiction on your side of the line.

Isolation you can demonstrate

Isolation is only useful if you can show it to an auditor. Running your databases on your own Kubernetes lets you choose the boundary explicitly. A namespace per tenant, with a network policy that blocks cross-tenant connections, a resource quota, and limit ranges, gives a hard per-tenant boundary. A denser shared tier, where small tenants are isolated logical databases with their own owner roles and public access revoked, trades that boundary for lower cost where the workload allows it. Either way, the boundary is a decision you made and can evidence.

Managed operations without a team per engine

The operational load is the honest downside of self-hosting: someone has to run backups, recovery, and upgrades for every engine. A platform approach closes most of that gap by giving every engine one lifecycle surface, create, resize, restart, upgrade, back up, and restore, and a validated backup-and-restore path per engine. You get managed-style day-two operations without handing the data to a third party.

The honest tradeoffs

Self-hosting is not free. You own the substrate, and a provider’s elastic autoscale and global footprint are things you give up. If a workload is non-regulated and bursty, a public managed service may be the right answer. The framework is about matching the model to the risk, not dogma.

Where Nothi fits

Nothi is a Kubernetes-native managed database platform you run on your own cluster. It turns a request for a database into a running, backed-up, metered instance inside an isolated tenant, across twelve engines, from one catalog-driven control plane. You keep the data, the keys, and the jurisdiction; the platform handles the lifecycle.