A PlanetScale clone isn’t a snapshot; it’s a live, read-only replica of your production schema, letting you experiment without fear.
Let’s see how this plays out in a real workflow. Imagine you’re on PlanetScale, and you’ve got your main production database. You want to test out a risky schema change, maybe adding a new users table with a complex uuid primary key and a created_at timestamp.
First, you navigate to your production database in the PlanetScale UI. You’ll see an option to "Create branch." You click it, and name your new branch add-user-uuid. PlanetScale then instantly creates a new branch. This isn’t copying gigabytes of data; it’s creating a new pointer to the existing data.
Now, here’s the magic: this add-user-uuid branch is live. It’s reading directly from the same underlying data as your production branch. If someone adds a new user in production right now, your add-user-uuid branch sees that change immediately without any replication lag.
You switch to the add-user-uuid branch. The schema editor shows you the exact schema of your production database. Now, you can add your new users table:
CREATE TABLE users (
id CHAR(36) PRIMARY KEY,
username VARCHAR(255) NOT NULL,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
You commit this change to the add-user-uuid branch. This commit is also instantaneous because it’s just a schema change on that branch. Your production branch remains completely unaffected.
You can now run queries against this branch. Let’s say you want to see if your new users table is correctly populated with sample data you might have seeded in production:
SELECT COUNT(*) FROM users;
This query runs against the production data, but through the lens of your new schema. If you had an INSERT statement in your production environment that added a user, this query would reflect that.
The benefit here is enormous. You can run performance tests, write integration tests, or even just explore the data using your new schema without ever touching production data or requiring a separate, slow data copy. If your CREATE TABLE statement had a mistake, or if your application code that interacts with the users table has a bug, you discover it here, on a branch, without any risk to your live application.
When you’re satisfied, you open a "Deploy request" in PlanetScale to merge your add-user-uuid branch back into production. PlanetScale shows you the schema diff, and you can approve it. This is where the actual schema change happens in production, and it’s a controlled, atomic operation.
The mental model to build is one of immutable, versioned schemas built on a shared, live data foundation. Each branch is a proposed state of the schema, and all branches read from the same, ever-evolving production data. The data itself is never "cloned" in the traditional sense; only the schema is branched and versioned.
The most surprising thing about PlanetScale branches is that they share the exact same underlying data without any latency. It’s not a replica that needs to catch up; it’s a different view onto the same, live data.
A common misconception is that you need to manually copy production data to test schema changes. PlanetScale’s branching model eliminates this entirely, allowing for near-instantaneous schema experimentation. You can even have multiple branches open, each with different schema experiments, all reading from the same production data.
The true power of this system emerges when you consider complex workflows. Imagine a feature flag that controls the visibility of a new table. You can create a branch, add the table, write your application code to use it behind the feature flag, and then merge that schema change to production before you even enable the feature flag in your application.
Once you’ve mastered schema branching, the next logical step is understanding how PlanetScale handles data migrations within this branching model.