PlanetScale offers undo button to reverse schema migration without losing data

Vitess-based database splits system for 30 minutes allowing users to right regrettable changes

Distributed transaction database biz PlanetScale has introduced an "undo" button it says can reverse schema changes, allowing devs to avoid embarrassing disasters by reverting to the original design without losing data within a 30-minute window.

Based on YouTube-developed distributed relational database Vitess, PlanetScale is a proprietary database-as-a-service designed to make life easier for developers than the open-source system. Based on MySQL, Vitess is used by the likes of Slack, Airbnb, and GitHub for its horizontal, globally scalable online transaction processing (OLTP) architecture. It has added SoundCloud, Solana, and MyFitnessPal as customers since it launched.

With the latest announcement, PlanetScale introduces an "Easy Button" to undo schema migrations that enables users to recover in seconds from changes that break production databases. Dubbed Rewind, the feature lets users "almost instantly" revert changes to the previous healthy state without losing any of the data that was added, modified, or otherwise changed in the interim.

It says the feature is an industry-first. Other databases claiming undo features only revert to snapshots while losing all of the data that had been ingested since the new schema was introduced, the company said.

PlanetScale VP of engineering Nick van Wiggeren told The Register Vitess contributors had built tools to make managing MySQL "really easy."

"We've built Rewind on top of a Vitess technology called V replication, which is like MySQL replication on steroids," he said. "It lets you do all kinds of... very impressive behind-the-scenes work to mung MySQL data the way that you want it. In short, Rewind works by leveraging Vitess V replication technology to tell MySQL to have two views of the world. You have a view of the world from before the schema change, you have a view of the world after the schema change, and it will actually kind of materialize both views of the world while you're writing data, because you [might] need to switch between the new and the old view of the world."

Van Wiggeren argued that 30 minutes was plenty of time to realize there was a problem with a schema migration. "I've worked at GitHub and plenty of other companies that use databases. In my experiences, when you have a bad schema migration, you know within about 30 seconds. Someone Slacks you and says the website down, or you hit refresh on your application monitoring system and there are thousands of error messages."

He said there was no appreciable impact on performance from using the features.

Andy Pavlo, associate professor of databaseology at Carnegie Mellon University, said PlanetScale had introduced a feature that would matter to developers.

"People often focus solely on performance metrics when evaluating database systems," he said. "This is a mistake because most applications are boring and they don't need sub-millisecond query latencies. But almost everyone will have to make schema changes in their applications, and this is where things can go horribly wrong.

"PlanetScale has done a good job prioritizing features in their database service that make it easier for app developers to maintain their applications. Along with their previously announced branch and non-blocking schema change features, the ability to quickly rollback a schema change makes it provide developers with an important escape hatch without losing data." ®