We used PlanetScale for a feature that required adding a composite index and changing a relationship across two tables that were already handling meaningful traffic. We spun up a development branch from main, applied the migration there, and ran our application tests against that branch before opening a Deploy Request. The diff surfaced an extra schema change that had accidentally slipped into the migration, so we removed it before approval. Because the new index touched a large table, we kept the deployment gated, let PlanetScale complete the synchronization work, and only did the cutover once the team was available to watch the metrics. Shortly after the cutover, Query Insights showed a related query reading far more rows than expected. The migration itself was fine; the issue was that the application query still used a filter pattern that prevented the new index from being used effectively. We corrected the query, saw latency drop, and avoided an unnecessary schema rollback. That’s the part I value most. PlanetScale didn’t make database changes risk-free, but it turned testing, review, deployment, and observability into a workflow that feels much closer to how we already ship code, instead of treating production schema changes like a separate ritual. Review collected by and hosted on G2.com.
Gated Deployments and Schema Revert have changed how we approach database releases because they give us more control over when the risky part actually happens. With a long migration, PlanetScale can do the copy and synchronization work up front while we decide when to trigger the final cutover. If a deployment causes trouble afterward, certain deploy requests can still be reverted within a 30-minute window, and when the schema change allows it, writes can be preserved. That makes release planning feel far less binary—we’re no longer forced to choose only between “ship now” and “wait for another maintenance window.” Query Insights has been just as valuable. It puts latency, query count, rows read and written, full table scans, and anomalous queries in one place, and it overlays deploy requests on the same timeline. That makes it much easier to tell whether a schema change actually caused a slowdown or whether it simply happened around the same time. We’ve also used the schema recommendations to catch missing indexes based on real traffic. In one case, what initially looked like a compute problem turned out to be a query doing far more work than it needed to. Review collected by and hosted on G2.com.