PlanetScale's documentation is worth reading for one section above all others, and it is the schema change workflow. The problem it addresses is one that every team running a relational database at any meaningful scale has experienced painfully. You need to add a column, or an index, or change a type. In development the migration takes two hundred milliseconds.
In production, against a table with three hundred million rows, the same statement takes a lock, the lock blocks writes, the writes queue, the connection pool exhausts, and your application is down. So teams invent coping strategies: run it at three in the morning, use a third-party online schema change tool with its own operational quirks, or simply never change the schema and accumulate a data model that nobody would design on purpose. PlanetScale's answer is to make schema changes a branch-and-deploy-request workflow. You branch, change the schema on the branch, open a deploy request that shows what will change, and the system applies it without blocking writes.
The mechanism inherits from Vitess and from years of operating MySQL at extremely large scale, and the documentation explains it well enough that you understand what guarantees you are getting rather than trusting that it works. The sharding material is the other genuine contribution. Horizontal sharding is the standard answer to scaling a relational database past a single machine and it is a difficult thing to do well. The hard parts are choosing a shard key you will not regret, handling queries that need to cross shards, resharding when your original key turns out to be wrong, and maintaining any semblance of transactional guarantees across the boundary.
The documentation is written by people who have done this rather than read about it, and the honesty about what becomes harder after sharding is the part I value most. A lot of scaling literature presents sharding as a solution; this presents it as a trade with a specific bill attached. The product has broadened considerably and the docs reflect that, now covering Vitess for MySQL compatibility, Postgres, and Neki as its own engine, with network-attached and Metal storage options for each. Metal, which puts data on locally attached NVMe rather than network storage, is documented with reasonable balance about when the latency gain is worth the operational difference, which is more nuance than a performance feature usually receives.
The breadth is a mixed blessing for a learner, though: three engines and two storage models is a lot of surface area, and someone arriving to learn about databases will find the choice architecture confusing before it becomes useful. The pricing situation needs stating clearly because there is genuine misinformation about it. PlanetScale removed its free Hobby tier in April 2024 and has not brought it back. PlanetScale's own documentation says plainly that it does not offer a free plan.
A number of third-party pricing aggregator sites currently claim otherwise, presenting a free tier that does not exist, and this appears to be the usual pattern of SEO-driven pricing pages that were written once and never revisited. Always check the vendor's own pricing page, and treat aggregator sites as a starting point rather than a source. The practical consequence is real: the cheapest entry is around five dollars a month for a single-node Postgres and around fifteen for a production three-node cluster, which is not expensive but does mean you cannot evaluate this on a hobby project for nothing, and that is a meaningful barrier for the learning use case specifically. Competitors offering free tiers will get more student and side-project adoption, and adoption at that end of the market has a way of becoming adoption at the other end five years later.
The Vitess constraint deserves a warning for anyone choosing the MySQL path. Vitess is a proxy layer that makes many MySQL databases look like one, and that abstraction has edges. Certain queries behave differently, some MySQL features are unavailable or restricted, and cross-shard operations have costs that a naive query will discover for you at an inconvenient moment. The documentation covers these constraints accurately and does not hide them, but they are the sort of thing that reads as a footnote during evaluation and becomes the central fact of your week six months later.
Read that section properly rather than skimming it. There is no teaching layer, as with every product documentation set in this batch. No course, no path, no certification. For a database platform aimed at engineers who already know SQL that is a reasonable choice, and the schema change and sharding sections are educational enough that they function as teaching whether or not they were intended to.
Three point six. Genuinely valuable engineering documentation on two problems most teams handle badly, honest about its constraints and its pricing, marked down for having no free tier for learners, no teaching layer, and a product surface that has grown faster than its onboarding narrative.