Running Non-Cloud-Native Databases in Cloud-Native Environments
summary
Shows concrete tactics and failures: use operators automate failover and upgrades but expect missing backup/restore bells, favor a replica model over StatefulSets, and budget for storage/network egress costs. Names and tools: MySQL (ProxySQL, Vitess), PostgreSQL (pgBackRest), ClickHouse (shared‑nothing, ClickHouse no single coordinator), Kubernetes, OpenTelemetry, Prometheus/Grafana, S3. Surprising scale examples: customers with 20+ petabytes and ~200‑node clusters; some automation works, some fixes still require manual rearchitecture.
AI-written summary · about
chapters (13)
- 0:00Introduction
- 1:10Legacy databases evolution
- 3:46Stateful design in old systems
- 8:02Why non-cloud-native matter
- 11:38Pain points in cloud-native
- 14:05Operators in automation
- 17:18Storage challenges
- 20:13MySQL/PostgreSQL setups
- 28:06Future of cloud-native DBs
- 33:47AI for DB operations
- 35:53Key takeaways
- 37:39Books and resources
- 39:27Q&A: PostgreSQL options
related talks
30mThe database trends that are transforming your database infrastructure forever
25mCloud Native Data on K8s: The Good, Bad, and the Unknown
28mLightning Talk: Cloud Native PostgreSQL - Running PostgreSQL on Kubernetes
31mOpen Source Databases on Kubernetes: Best Practices
41mCloud-Native Databases in Kubernetes with OpenShift and Postgres
28mCloud Native Tech: The Building Blocks of Modern DB Software
50mFrom VMs to Cloud-Native PostgreSQL in Kubernetes...
50mDemystifying Kubernetes for Postgres DBAs; A Guide to Operators