Panel Discussion: Databases
summary
Panelists compare concrete tradeoffs for databases: MongoDB transactions add latency and split‑brain risk, so teams sometimes replace MongoDB when they need strong transactions. Running databases in Kubernetes can work for ephemeral staging but risks Docker filesystem issues and operational complexity for stateful masters; memory spikes usually come from bad queries or misconfiguration and are fixed by query rewriting, proper RAM limits and sharding; zero‑downtime schema migrations are handled by staged field additions, review processes and load testing.
AI-written summary · about
chapters (11)
- 0:00Welcome
- 2:38Performance stories
- 4:24Databases in Kubernetes
- 10:04MongoDB transactions
- 17:50Call Me Maybe analysis
- 19:15MySQL to Neo4j
- 20:18Graph databases in production
- 23:50MySQL memory usage
- 27:00Data behind firewall
- 29:00Schema changes without downtime
- 33:18Closing
related talks
08mLightning Talk: Should You Run Your Database on Kubernetes
26mChallenges of Managing Stateful Applications in Kubernetes
29mModern Database Architecture: From SQL to NoSQL & Distributed SQL
35mAn Ode to 17 Databases in 39 minutes
01h 06mPanel: Running Databases in Containers
29mDatabases with Kubernetes
18mDave Stokes Talks Open - Episode 6
45mFrom Laptop to Cloud: Developing Cloud Native Applications with Containerized Databases