PlanetScale’s serverless MySQL isn’t actually serverless in the way you might think, and Aurora’s "serverless" is a bit of a misnomer too, making the comparison more about different approaches to scaling and managing MySQL than a strict serverless vs. provisioned debate.
Let’s look at PlanetScale first. Imagine you’re building a web app and need a database. Traditionally, you’d spin up a MySQL instance on a server, manage its resources, handle backups, and scale it manually. PlanetScale offers a different path.
Here’s a PlanetScale schema definition:
CREATE TABLE users (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
username VARCHAR(50) NOT NULL UNIQUE,
email VARCHAR(100) NOT NULL UNIQUE,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
CREATE TABLE posts (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
user_id BIGINT UNSIGNED NOT NULL,
title VARCHAR(255) NOT NULL,
content TEXT,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE
);
When you create this in PlanetScale, you’re not provisioning a VM or a specific instance size. Instead, PlanetScale uses Vitess under the hood, a database clustering system designed for horizontal scaling and management of MySQL. What feels "serverless" is that PlanetScale abstracts away the underlying infrastructure. You don’t worry about patching operating systems, managing replication lag, or manually adding read replicas. PlanetScale handles this automatically. Your database scales as your load increases, and you’re billed based on usage (data stored, queries processed). The "serverless" aspect is really about the operational burden being removed.
Now, let’s consider AWS Aurora. Aurora is a MySQL-compatible relational database built for the cloud. Its "serverless" offering, Aurora Serverless v1 and v2, is where things get interesting. Aurora Serverless does automatically scale compute capacity up and down based on your workload. When your application traffic drops, Aurora Serverless can scale down to zero Aurora Capacity Units (ACUs), meaning you pay nothing for compute during idle periods.
Here’s a simplified look at how Aurora Serverless v2 might configure itself:
When Aurora Serverless v2 detects a sustained increase in read traffic, it might automatically provision a new read replica instance behind the scenes. Conversely, if read traffic drops significantly, it might deprovision that replica. This scaling is managed by AWS, and you don’t interact with specific instance types like db.r5.large.
The key difference: PlanetScale’s "serverless" is about managed infrastructure and scaling via Vitess, where the underlying database instances are always running but managed for you. Aurora Serverless is about dynamically scaling compute capacity, including scaling down to zero for cost savings during idle times.
The problem PlanetScale solves is the complexity of scaling and managing traditional MySQL in a distributed environment. Vitess allows PlanetScale to shard databases automatically, distribute queries, and handle failovers without manual intervention. This is crucial for applications with massive datasets or high, unpredictable traffic patterns.
Aurora Serverless, on the other hand, aims to solve the problem of over-provisioning and under-utilization common with traditional relational databases. You pay for what you use, and the database scales compute on demand. This is ideal for variable workloads, development/testing environments, or applications with infrequent but sometimes intense usage.
The mental model for PlanetScale is a highly automated, horizontally scalable MySQL cluster. You define your schema, and PlanetScale (via Vitess) handles the distribution, replication, and scaling of that schema across many underlying MySQL instances. You interact with it like a single MySQL database, but under the hood, it’s a distributed system.
For Aurora Serverless, the mental model is a MySQL-compatible database whose compute power adjusts automatically. You still think about database instances and configurations, but the amount of compute is dynamic. You set minimum and maximum ACUs, and Aurora manages the transitions.
The one thing most people don’t grasp is how Vitess in PlanetScale enables true horizontal sharding. When your users table gets millions of rows, PlanetScale can automatically split that table into smaller pieces (shards) based on a chosen key (e.g., user_id). Queries that would have scanned the entire table now only need to hit specific shards, dramatically improving performance. This isn’t just about adding more read replicas; it’s about fundamentally restructuring how data is stored and accessed.
The next concept you’ll likely encounter is understanding how to effectively leverage Vitess’s sharding capabilities within PlanetScale for optimal query performance and scalability.