The "Next.js 12" conference came with a lot of exciting news for the dev community. One of the big discoveries for me was PlanetScale. In a nutshell, PlanetScale is a serverless database platform built on MySQL and Vitess. What's making it special is its ability to create branches of the main database during development and deployment. If you're familiar with Git, this concept is almost the same as code versioning. PlanetScale's VP of engineering, Nick Van Wiggeren, used to work at Github so that could have explained it. You might be thinking, why would I care about database versioning? After all, whenever I push a commit that involves database changes, I could see all the migrations and metadata diffs on the pull request, could'nt I? And, you're not wrong for thinking that. However, as "all roads lead to Rome", the path that PlanetScale is paving might be an improvement to our current workflow.

As technology evolves, there's is idea of localization and segregation. We see this a lot in single-responsibility principle or React components. Then, why can't we apply the same idea to functional codes and database codes? Every time we deploy a PlanetScale schema change, it's treated as a pull request which database cluster is completely isolated from the production database. We can commit the changes to a branch, run migrations, get a diff, and run tests as part of a CI/CD workflow. When the PR is approved, the branch can be merged into production just like how normal PRs are squashed and merged into main on Github. Concurrency is an important problem, especially when it comes to production's schema changes. What happens if we're adding a new column to a table and that table is being read from and written to by users at the same time? PlanetScale solves this by asynchronously rolling out the changes into production. The action pauses if they see a burst of traffic and resumes when it's safe. We can visualize it as a stack where migration tasks are executed one by one and traffic's requests could jump on top the stack at anytime and causes the migration to pause. It's a non-blocking deployment of database changes. This is better than, let's say, plainly executing schema changes with SQL because a SQL command would lock the table and cause significant downtime for users.

Overall, it's an interesting time in the database world. I'm just a bit disappointed that I'm a big fan of Hasura GraphQL API which currently only integrates with PostgreSQL which is not yet supported by PlanetScale. I find PlanetScale's API not matured enough to provide the best user experience. It also hasn't had a UI for interacting with the relational tables yet. The good news, though, is that Hasura is reportedly rolling out MySQL support later this year which may complement what PlanetScale is lacking 🎉