Running OSS Databases on AWS · April 24, 2026
In the Cloud?
Be Cloud-Ready Instead.
Option 1 — The Default Path
Managed Services on AWS
Someone asks "how do I run Postgres on AWS?" — you say RDS. It's the fastest path to a running database.
Day 2 Reality
The Promise vs. The Reality
| ✓ What They Promise | ✕ What You Get at Scale | |
| Pricing Pay as you go — only what you use | Pricing Data egress fees that look like ransom notes Moving 1TB from RDS → anywhere costs $90 in transfer alone. Plus the engineer-hours. | |
| Operations No DBA needed — fully managed | Operations You still need a DBA — plus a cloud engineer AWS handles the OS. Query tuning, index design, slow log triage — that's still your DBA. And wiring IAM, VPC, and parameter groups needs someone who knows AWS. | |
| Reliability 99.99% SLA — production ready | Reliability Regional outages — zero control, full blast radius When us-east-1 goes down, so does your runbook. You're a passenger. | |
| Portability Standard SQL, export anytime | Portability Proprietary Aurora APIs, no standard export path RDS Proxy, Aurora-specific parameter groups, and AWS-only storage formats. Migration is a rewrite. |
The False Sense of Security
Terraform manages lifecycle,
not logic.
resource "aws_db_instance" "main" { engine = "postgres" instance_class = "db.r6g.xlarge" multi_az = true }
resource "google_sql_database_instance" "main" { # Different networking model# Different IAM/auth system# Different backup semantics# Different driver compat }
Infrastructure as Code ≠ Infrastructure as Portable. Terraform abstracts the API calls. It doesn't abstract the networking model, IAM structure, connection strings, driver compatibility, or proprietary SQL extensions baked into your schema.
Option 2 — The DIY Path
Self-Managed on EC2
No vendor lock-in, full control. You install the database, you write the scripts, you own all of it.
Looks Simple
# or: AWS Marketplace AMI
# or: Ansible playbook
systemctl enable postgresql
- Pick any version, any config
- Full OS-level access
- Marketplace AMIs for quick bootstrap
- No AWS API lock-in
The Ops Pile-Up
- Manual failover via SSH + runbook
- Backup cron jobs you wrote and forgot
- Version drift across instances
- No observability without custom setup
- Security patches = scheduled downtime
Unmanageable
- 12 databases × 3 versions × N teams
- Ticket-driven ops — every change is a request
- "Don't touch it, it's been stable for 8 months"
- No one remembers what the scripts do
- DBA becomes the bottleneck for everything
Part II
Kubernetes:
The Universal Cloud OS
A standardized abstraction layer for infrastructure — the same API whether you're on EKS, GKE, or bare-metal.
Kubernetes Portability
Same API. Different Engines.
Your manifests stay identical. The cloud underneath is just an implementation detail.
Your application YAML is identical on both.
Change storageClassName and cloud annotations — not your app code, not your schema, not your operator CRDs.
The Real Cost
Kubernetes is complex.
Databases multiply it.
Running stateful workloads means owning every layer — both the platform and the engine on top of it.
No pager escalation path? No runbook? Not a managed service's problem — it's yours.
The Building Block
Kubernetes Operators: The Game Changer
What the Operator Does for You
Day-2 Operations — Built In
The operator is a DBA encoded in software. It knows your database, not just Kubernetes.
Devil's Advocate
OK, but it's still not one click.
The manifest is portable. The terabytes inside it are not.
Same YAML. EKS, GKE, AKS, bare metal.
Zero changes required.
CSI drivers are not interoperable
Moving the Data
Three Migration Paths
Pick based on how much downtime you can afford.
Path 1 · Medium Downtime
PVC Migration
Path 2 · Low Downtime
Backup & Restore
Path 3 · Near-Zero Downtime
Live Replication
The Next Problem
Great. Now You Have Five Operators.
Your stack has PostgreSQL, MySQL, MongoDB, Redis — each one brought its own operator, its own CRDs, its own operational model.
operators
operators
operators
operators
OperatorHub
The operators are mature. The missing piece is the control plane above them — something that speaks all their dialects and gives you one consistent interface.
Introducing
A unified, open source control plane for running production databases on any Kubernetes cluster — any cloud, any engine.
development
across organizations
vendor lock-in, ever
OpenEverest is a CNCF Sandbox project — part of the Cloud Native Computing Foundation ecosystem OpenEverest · AWS EKS
Deploying on EKS
Production-grade databases on your cluster — AWS-native storage, auth, and networking included
Quick Start with Helm
A single Helm command bootstraps the full control plane. Works with EKS 1.27+, compatible with eksctl, Terraform, and all GitOps toolchains.
helm install openeverest \ oe/openeverest -n openeverest \ --create-namespace
AWS Storage & Backups
EBS CSI driver provisions per-database gp3 volumes with automatic resizing. S3 handles scheduled backups — no cron scripts, no manual dumps, point-in-time restore included.
Cloud-Native Integrations
IRSA for zero-secret credential management. ALB / NLB for resilient database endpoints. Multi-AZ failover with automated recovery across availability zones.
OpenEverest — What's Next
The Road Ahead
We're building the platform in the open — and we want you to help shape it
Modular Architecture
Plug in any data engine, storage backend, or AI tool via the plugin system. Operators, monitoring, backup adapters, custom tooling — all composable, all replaceable. No monolithic lock-in at the platform level.
Multi-Cluster Deployments
A unified control plane across multiple Kubernetes clusters — cloud, on-prem, or hybrid. Manage databases spanning regions and environments from a single UI, with consistent policy and observability.
Migrations Made Easier
Plugins aren't just for operations — they discover data, execute transforms, and wire up migrations between engines and environments. Moving off RDS? Shifting clouds? The platform does the heavy lifting.
We're building this in the open. Come help us build the future of database infrastructure on Kubernetes.
Thank you!
Questions?
Sergey Pronin · Founder, Solanica Inc. · Maintainer, OpenEverest · BuildDevCon, April 2026