Your Kubernetes cluster runs everything. Compute is paid for. But the database? That lives on RDS, adding $800/month and 20ms to every query.
The math doesn’t work
A db.t3.medium on RDS costs $55/month. Reasonable. Then you enable Multi-AZ for high availability—that doubles the instance cost to $110. You need consistent performance, so you switch to provisioned IOPS. Now you’re paying $0.10 per IOPS-month. 3,000 IOPS with Multi-AZ? That’s $600/month just for storage performance. Add your storage, data transfer, and backups. You’re at $750-800.
Meanwhile, your Kubernetes cluster has spare capacity sitting idle. The compute is there. The storage is there. You’re just not using it for databases because “Kubernetes can’t handle stateful workloads.”
That was true in 201…
Your Kubernetes cluster runs everything. Compute is paid for. But the database? That lives on RDS, adding $800/month and 20ms to every query.
The math doesn’t work
A db.t3.medium on RDS costs $55/month. Reasonable. Then you enable Multi-AZ for high availability—that doubles the instance cost to $110. You need consistent performance, so you switch to provisioned IOPS. Now you’re paying $0.10 per IOPS-month. 3,000 IOPS with Multi-AZ? That’s $600/month just for storage performance. Add your storage, data transfer, and backups. You’re at $750-800.
Meanwhile, your Kubernetes cluster has spare capacity sitting idle. The compute is there. The storage is there. You’re just not using it for databases because “Kubernetes can’t handle stateful workloads.”
That was true in 2018. It’s not true anymore.
Serverless doesn’t fix it
Maybe you’re not on RDS. Maybe you went with Neon or PlanetScale because the pricing looked simpler. Pay for what you use. Scale to zero. No provisioning decisions.
Then you hit the compute-second bills. Or the storage costs that never go down. Or the branching fees. The invoice arrives and it’s $200 for a database that could run on a $5 VPS.
Serverless databases trade provisioning complexity for pricing complexity. You’re still paying a premium for someone else to run Postgres.
How we got here
Ten years ago, companies had DBAs. People who understood Postgres internals, managed replication, and got paged at 3am. Then managed databases promised to make that expertise unnecessary. Click a button, get a database. Let Amazon worry about it.
It worked. Teams stopped learning how databases actually run. The DBA role evaporated. And when the bills started climbing, nobody knew enough to question whether there was another way.
The fix exists
CloudNativePG is a Postgres operator for Kubernetes. Automatic failover, streaming replication, continuous backup to S3, point-in-time recovery. It’s a CNCF Sandbox project with 9,000+ GitHub stars and 58 million downloads.
It’s not experimental. Google Cloud, Microsoft Azure, IBM, Akamai, and GEICO run it in production. Mirakl runs 300+ clusters on it. Novo Nordisk uses it. The adopters list has 40+ organizations.
Teams that switch typically see 70-80% cost reduction. Query latency drops from 15-20ms to sub-millisecond. The database runs where the application runs. The math finally works.
So why isn’t everyone using it?
Because it’s built for platform engineers
Creating a database means writing a 40-line YAML manifest. Configuring backups means creating secrets, referencing them correctly, hoping the S3 bucket policy is right. Checking backup status means parsing kubectl output.
For most teams, every database request becomes a ticket to the infrastructure team. Developers can’t self-serve. The platform team becomes a bottleneck. The RDS bill is replaced with an operational tax.
That’s what Launchly fixes
Launchly is a UI for CloudNativePG. Create databases, configure backups, monitor clusters. No YAML. No kubectl. The interface that CloudNativePG should have shipped with.
A lightweight agent runs in your cluster and connects to Launchly over WebSocket. When you create a database in the UI, the command goes to your agent, which applies the CloudNativePG manifest locally.
Your data never leaves your infrastructure. Credentials, secrets, everything stays in your cluster. Launchly is a control plane, not a data plane. If our service goes down, your databases keep running.
Not everything needs 100% availability
Maybe you’re not ready to move production. That’s fine. But how many databases are you running that aren’t production?
Dev environments. Staging. QA. Feature branches. Internal tools. Analytics pipelines. You’re probably paying RDS or Neon prices for databases that could tolerate a few minutes of downtime during a failover.
Start there. Run your non-critical workloads on CloudNativePG. See how it behaves. Watch the costs drop. When you’re comfortable, move the rest.
If you’re running Kubernetes and tired of the database bill, this might be worth a look. Free during beta.
Try it out
Free during beta. Setup takes about 5 minutes with an existing Kubernetes cluster.
Questions? [email protected]