Architecting Database deployments on Kubernetes: Patterns, Trade-offs and Experiences

Running large-scale database workloads on Kubernetes (K8s) is a decision an increasing number of organizations are making today. Modern Operators—whether for Postgres, MySQL, MongoDB, or Valkey—provide the essential software backbone, but they are only one part of the equation. While Operators provide the baseline automation for Postgres, MySQL, MongoDB, and Valkey, they do not solve the fundamental infrastructure design decisions that dictate system stability and performance at scale. A challenge lies in designing the K8s, Operator, and Databases environment that provides this deployment at scale tailored for each organization’s requirements. This session moves beyond basic deployment to examine the architectural choices that architects and engineers face when deploying databases on Kubernetes. We will dissect the technical implications of different design patterns, examining decision points such as:

• Kubernetes cluster to database cluster mapping
• Worker node allocation strategies
• Operator deployment strategies (per namespace vs cluster-wide)
• Multi-database implications Each option and architectural choice poses its own unique set of constraints, trade-offs, and capabilities for balancing resource overhead, complexity, and isolation. We will analyze the trade-offs of these patterns with regard to complexity, resource consumption, operational overhead, scalability, and isolation, utilizing lessons learned and experiences from real-world deployments. By the end of this talk, attendees will leave with a decision framework for evaluating these topologies, enabling them to match their Kubernetes database architecture to their specific requirements for availability, isolation, and operational overhead.