Originally announced via GlobeNewswire on June 16, 2020. Mountain View, Calif.
PlanetScaleDB for Kubernetes: Managed Databases Inside Your Own Cluster
PlanetScale announced the beta release of PlanetScaleDB for Kubernetes, a solution that lets organizations host their databases inside their own network perimeter while still benefiting from a fully managed, SaaS-like operational experience. Deployment is handled through the PlanetScale control plane and a Kubernetes operator, aiming to reduce the operational burden of backups, high availability, and software upgrades to just a few clicks.
PlanetScaleDB for Kubernetes is a MySQL-compatible database-as-a-service designed for teams running distributed, containerized workloads on Kubernetes—whether on-premises or in a public cloud.
Built on Vitess: A Battle-Tested CNCF Project
The underlying engine for PlanetScaleDB is Vitess, a top-level Cloud Native Computing Foundation (CNCF) open source project. Vitess was originally developed at YouTube to handle massive MySQL sharding at scale and has since been adopted by companies including GitHub, HubSpot, Slack, and Square to serve millions of queries per second.
By building on Vitess, PlanetScaleDB inherits horizontal sharding, connection pooling, and topology management capabilities that are difficult to implement with standard MySQL deployments. Organizations that need MySQL compatibility but require Kubernetes-native scalability are the primary target audience.
Why Bring the Database Into the Kubernetes Cluster?
As Kubernetes adoption has accelerated, a common architectural tension has emerged: application workloads run inside a Kubernetes cluster while the database lives outside it, often in a managed cloud service or a separate VM-based environment. This separation introduces network latency, complicates security policy enforcement, and creates operational silos between application and data teams.
PlanetScaleDB for Kubernetes addresses this by co-locating the database with the application workloads inside the same cluster. According to PlanetScale, running the database adjacent to microservices can reduce query latency by up to 20 milliseconds—though this figure will vary significantly depending on existing network topology and workload characteristics.
Key Features
- Efficiency: Co-locating databases and applications in the same Kubernetes cluster eliminates the need for complex cross-network infrastructure.
- Performance: Reduced network hops between microservices and the database layer lower query latency.
- Reliability: PlanetScaleDB manages software upgrades, hardware failure recovery, and network partition handling without requiring application downtime.
- Security: Because data remains within the customer’s own network perimeter, it is easier to enforce internal security policies and compliance requirements.
- Ease of Operations: The PlanetScale control plane and Kubernetes operator handle day-two operations—backups, scaling, and failover—as a managed service.
- MySQL Compatibility: Applications that already use MySQL drivers and tooling can connect without changes to the application layer.
How the Operator Model Works
PlanetScaleDB for Kubernetes uses the Kubernetes Operator pattern: a custom controller watches for PlanetScaleDB custom resources and reconciles the actual cluster state to match the desired state declared in those resources. This means database provisioning, scaling, and lifecycle management are expressed as Kubernetes manifests and handled natively by the Kubernetes API server, rather than through a separate out-of-band management tool.
The PlanetScale control plane provides a management UI and API layer on top of the operator, delivering the simplified “few clicks” provisioning experience the company describes for teams that do not want to write raw Kubernetes manifests.
Target Use Cases
- Regulated industries where data residency and network perimeter requirements prevent use of external managed database services.
- Hybrid cloud environments where workloads span on-premises Kubernetes clusters and public cloud infrastructure.
- High-throughput transactional workloads that need horizontal sharding beyond what a single MySQL instance can provide.
- Teams migrating from VM-based MySQL to a Kubernetes-native stack without rewriting application database logic.
Availability
At the time of this announcement (June 2020), PlanetScaleDB for Kubernetes was in beta. For current availability, pricing, and documentation, visit planetscale.com directly, as the product has continued to evolve since this announcement.
PlanetScale can also be followed on Twitter at @planetscaledata.