PlanetScale: Serverless MySQL and the Vitess Story

PlanetScale is a database-as-a-service (DBaaS) company that provides a serverless, MySQL-compatible database platform. Its core technology is built upon Vitess, an open-source database clustering system originally created at YouTube to solve the challenges of massive-scale data storage and retrieval. The company's primary value proposition is to offer the power of Vitess, specifically its ability to horizontally scale a relational database, as a fully managed service, while adding a developer-centric workflow that includes features like database branching and non-blocking schema migrations.

For developers and technical leaders, PlanetScale aims to solve a long-standing problem: the difficulty of scaling traditional relational databases. As an application grows, a single database server can become a bottleneck. The conventional solution, known as sharding, involves manually splitting a database across multiple servers. This process is complex, operationally intensive, and fraught with risk. PlanetScale automates and manages this complexity, allowing application developers to treat a distributed database cluster as if it were a single, highly scalable MySQL instance.

History and Origins

The story of PlanetScale is inseparable from the story of Vitess.

The Genesis of Vitess at YouTube

In the late 2000s and early 2010s, YouTube's rapid growth placed immense strain on its underlying MySQL database infrastructure. The engineering team faced the challenge of scaling the database horizontally to handle an exploding volume of users, videos, and metadata. To solve this, a team at YouTube began developing a middleware solution to shard MySQL. This project, initiated around 2010, became Vitess. Key figures in its creation included Jiten Vaidya and Sugu Sougoumarane.

Vitess acted as a proxy layer that sat between the application servers and a large fleet of MySQL instances. It handled connection pooling, query routing, and automated sharding, making the cluster of databases appear as a single logical unit. This allowed YouTube to scale its database tier without requiring significant changes to the application code. Google, YouTube's parent company, later donated Vitess to the Cloud Native Computing Foundation (CNCF) in 2018^[1], where it eventually became a Graduated project in November 2019.

Company Formation and Funding

Recognizing the broader applicability of Vitess beyond Google, two of its creators, Jiten Vaidya and Sugu Sougoumarane, founded PlanetScale in 2018. The company's initial mission was to provide enterprise support and managed hosting for Vitess clusters across multiple cloud environments. PlanetScale is currently headquartered in San Francisco, California^[2].

PlanetScale has progressed through several significant funding rounds:

• Seed Round: In late 2018, the company raised a $3 million seed round led by SignalFire.
• Series A: In May 2019, PlanetScale raised a $22 million Series A led by Andreessen Horowitz (a16z). Around October 2020, Sam Lambert, formerly the VP of Engineering at GitHub, joined as Chief Product Officer. Lambert would later become CEO of the company^[3].
• Series B: The company announced a $30 million Series B in June 2021, led by Insight Partners. This coincided with the general availability of its serverless database platform, marking a pivot toward a more focused DBaaS product.
• Series C: In November 2021, PlanetScale secured a $50 million Series C led by Kleiner Perkins, which brought its total funding to over $105 million.

Core Technology and Product Features

PlanetScale's product is more than just a managed Vitess offering. It combines the scaling power of Vitess with a unique set of features designed to improve the developer workflow.

The Vitess Engine

At its heart, PlanetScale is powered by Vitess. Vitess is not a new database engine; it's a clustering system that manages a fleet of standard MySQL instances. Its architecture includes two primary components:

1. VTgate: A stateless proxy that routes application queries to the correct underlying MySQL shard. It understands the sharding scheme and can split a single query across multiple shards and aggregate the results. This makes the sharded architecture transparent to the application.
2. VTtablet: A proxy that runs alongside each MySQL instance. It manages the lifecycle of the MySQL process, provides connection pooling, rewrites queries for performance and safety, and manages replication topology.

Vitess enables features like online schema migrations and resharding, which PlanetScale exposes to its users through a simplified interface.

Database Branching

PlanetScale's most distinctive feature is database branching^[4]. Drawing an analogy from version control systems like Git, this feature allows a developer to create an isolated copy of a database schema. This "development branch" is a fully functional database that can be used to experiment with schema changes, run tests, or develop new features without any risk to the production environment.

When a developer is satisfied with the changes made in a branch, they can open a "deploy request." This is conceptually similar to a pull request in GitHub. The deploy request shows a diff of the schema changes and, once approved and merged, applies those changes to the production database.

Non-Blocking Schema Migrations

The deploy request process is powered by Vitess's underlying online DDL (Data Definition Language) capabilities. When a schema change is deployed, PlanetScale uses a mechanism that avoids locking tables. It creates a "ghost" table with the new schema, copies data from the original table in the background, and then performs a quick, atomic cutover. This process, often referred to as an online schema change^[5], ensures that the database remains highly available and performant during migrations, a common pain point for teams managing large MySQL databases.

PlanetScale Insights and Revert

To complement its core workflow, PlanetScale provides a performance monitoring tool called Insights. It allows developers to analyze query performance, identify slow queries, and understand database usage patterns. The platform also offers a schema revert feature^[6], which allows a team to quickly undo a schema change that has caused unforeseen problems, providing an important safety net.

Business Model

PlanetScale operates on a consumption-based pricing model^[7]. Customers are billed based on three primary metrics: the number of rows read, the number of rows written, and the amount of data stored. This serverless model means users pay for what they use, and the platform automatically scales resources to meet demand without requiring users to provision servers or instance sizes.

The company offers several plans, including a free tier for developers and paid plans that offer higher limits, more advanced features, and dedicated support. This model is designed to align with the growth of an application; costs are low for small projects and scale up as traffic and data volume increase.

In early 2024, PlanetScale made a significant change to its pricing structure by discontinuing its generous "Hobby" plan^[8], which had offered substantial free usage allowances. The free Hobby plan was completely discontinued with no free replacement tier; users were required to upgrade to a paid plan. The company stated the change was necessary to ensure the long-term sustainability of the platform and to curb abuse of the free tier. This decision generated considerable discussion and criticism from the developer community, with some users expressing disappointment and announcing plans to migrate to other services. The company's public rationale was that the previous free tier was being used for production workloads far beyond its intended scope, creating an unsustainable cost structure.

Market Position and Competitors

PlanetScale competes in the crowded and highly competitive cloud database market. It is often categorized as a Distributed SQL or NewSQL database, though its approach of scaling a traditional engine (MySQL) differs from some competitors that have built new engines from scratch. Its main competitors include:

• Amazon Aurora: A cloud-native relational database offered by AWS, compatible with both MySQL and PostgreSQL. Aurora's primary innovation is its distributed storage layer, which provides high availability and read scalability. While Aurora excels at scaling reads, PlanetScale's architecture, based on Vitess, is explicitly designed for horizontal write scaling via sharding. Aurora is deeply integrated into the AWS ecosystem, while PlanetScale offers a multi-cloud presence.

• CockroachDB: A distributed SQL database built from the ground up for global scale and high resilience. It is wire-compatible with PostgreSQL^[9]. Unlike PlanetScale, which scales MySQL, CockroachDB is its own database system. The choice between them often comes down to ecosystem preference (MySQL vs. PostgreSQL) and specific architectural needs for multi-region data distribution.

• TiDB (from PingCAP): An open-source, MySQL-compatible, distributed SQL database. Like PlanetScale, TiDB is designed for horizontal scalability and is compatible with the MySQL protocol. It uses a different underlying architecture, with the TiKV transactional key-value store^[10] as its storage layer. PingCAP offers a managed service, TiDB Cloud, which is a direct competitor to PlanetScale.

• Traditional Managed Databases: Services like Google Cloud SQL, Azure Database for MySQL, and Amazon RDS provide managed instances of standard MySQL. These are excellent choices for applications with predictable scale but lack the built-in horizontal sharding and advanced developer workflow features that define PlanetScale.

Strengths and Limitations

Like any technology, PlanetScale has a distinct set of advantages and tradeoffs that make it suitable for certain use cases.

Strengths

• Massive Horizontal Scaling: By using Vitess, PlanetScale is engineered to handle workloads that grow far beyond the capacity of a single server. This is its core technical advantage.
• Superior Developer Experience: The Git-like branching workflow and non-blocking schema migrations are widely praised features. They integrate database changes into modern CI/CD pipelines and remove a major source of operational pain and downtime.
• MySQL Compatibility: By building on MySQL, PlanetScale allows organizations to use a familiar, mature technology. The vast ecosystem of MySQL clients, tools, and developer expertise can be used with PlanetScale, lowering the barrier to adoption.
• Fully Managed Service: PlanetScale abstracts away the immense operational complexity of running, monitoring, and scaling a distributed Vitess cluster. This allows engineering teams to focus on application development rather than database administration.

Limitations and Criticisms

• Foreign Key Constraints: As of February 2024, PlanetScale supports foreign key constraints for unsharded databases, though not for sharded ones. The company's official documentation explains that foreign keys are difficult to manage in a distributed, sharded database system and can cause significant performance and availability issues at scale. As a result, in sharded databases, referential integrity must be maintained by the application logic. This remains a fundamental architectural tradeoff for teams that rely on the database to enforce data relationships across shards.
• Vendor Lock-in: While Vitess is open source, the PlanetScale platform and its unique workflow features (like the branching UI and deploy request system) are proprietary. Migrating a large application off PlanetScale to a self-hosted Vitess cluster is theoretically possible but would require significant engineering effort to replicate the managed experience, creating a degree of platform lock-in.
• Pricing Model Volatility: The 2024 decision to curtail the free tier demonstrated that, like any managed service, pricing and plan structures can change. This event caused concern among some users about the platform's long-term cost predictability, especially for smaller projects and startups.
• Vitess Abstractions: While PlanetScale hides most of Vitess's complexity, it is not a perfect abstraction. Certain query patterns that work on a single MySQL node may not be performant or may behave differently in a sharded environment. Developers still need to be mindful that they are working with a distributed system.

Decision Lens for Technical Leaders

Evaluating PlanetScale requires weighing its powerful scaling and developer workflow features against its architectural tradeoffs.

When to Choose PlanetScale

PlanetScale is an excellent fit for:

• High-Growth Applications: For products built on a MySQL-compatible stack that are expected to experience rapid user growth and require horizontal write scaling.
• Modern DevOps Teams: For organizations that want to treat their database schema as code and integrate database changes safely and automatically into their CI/CD pipelines.
• Teams Prioritizing Velocity and Reliability: For developers who want to eliminate downtime caused by schema migrations and offload the operational burden of database management.
• Architectures That Can Forgo Foreign Keys: For applications where referential integrity can be managed at the application layer, or for use cases where it is not a critical requirement.

When to Consider Alternatives

PlanetScale may not be the right choice for:

• Applications Requiring Foreign Keys: If database-enforced foreign key constraints are a non-negotiable architectural pillar, another database like a standard managed MySQL, PostgreSQL, or CockroachDB would be more suitable.
• Small, Stable, or Cost-Sensitive Projects: For applications with predictable, low-to-moderate scale, a traditional managed database like Amazon RDS or Google Cloud SQL is often simpler and more cost-effective.
• PostgreSQL-Centric Teams: If an organization's tooling, expertise, and application stack are built around PostgreSQL, alternatives like Amazon Aurora for PostgreSQL, CockroachDB, or Neon are more natural fits.
• Complex Transactional Workloads: Systems requiring complex, cross-shard distributed transactions or specific analytics features might find the limitations of the Vitess query planner restrictive.