Challenges of running data stores in containers
summary
Runs neo4j clusters on Kubernetes using a custom operator that manages 3‑node Raft clusters (majority required for writes), mounts data outside containers, and keeps local SSDs for performance while pushing incremental backups to remote distributed storage for disaster recovery. Warns that hostPath is brittle; prefer local persistent volumes, test block vs network storage (remote is often much slower), set CPU requests/limits to avoid noisy neighbors, prefer DNS A/SRV or service VIPs over random host ports. The operator approach works in production.
AI-written summary · about
chapters (16)
- 0:00Introduction to talk
- 1:52Databases in containers today
- 2:56Traditional beefy server setup
- 5:48Containers and orchestration basics
- 7:14Data persistence in containers
- 9:00Clustering for resilience
- 10:07Storage options and trade-offs
- 12:35Resource utilization benefits
- 14:05CPU and network isolation
- 18:27Port conflicts and networking
- 21:20Service discovery in containers
- 23:29Backup strategies for data safety
- 24:54Orchestration essentials
- 27:00Choosing container orchestrators
- 28:03Neo4j Cloud implementation
- 32:40Summary and Q&A
related talks
24mDynamic Big Data in the Cloud with Kubernetes
35mOrchestrating Resilient Data: Harnessing the Strength of Kubernetes with Operators
41mDatabases on Kubernetes Using a Custom Operator: Day 1, Day 2, and Beyond
08mLightning Talk: Should You Run Your Database on Kubernetes
10m⚡ Lightning Talk: Navigating the Complexities of Stateful Workloads in Kubernetes
01h 06mPanel: Running Databases in Containers
47mFrom a Database in Container to DBaaS on Kubernetes
45mDatabases on Kubernetes: Why you should care