A few days ago, we were preparing a new feature that required various schema changes. Part of this involved maintaining a table for our users, who are currently stored only on Clerk. We previously used Next-Auth but switched to Clerk. Although most user IDs were pointing to Clerk, some relations still referred to the old User table, but we stopped storing users in our own table.

The plan was to create a new ClerkUser table and update all relations to point to the new ClerkUser using the user_id. This way, I could join the ClerkUser on database calls instead of making a separate call to Clerk afterward. Once the schema was deployed, I would backfill our users and listen for webhooks to update or create new users. What could go wrong?

So, I deployed the schema change and...

It turned out that dropping multiple columns, some with valid relations to the old User table, was NOT a good idea! Production went down. 😔If I had not been using PlanetScale, I would have been in serious trouble because the data in those columns was gone, and I was not ready to push codebase changes to production.

Fortunately, using the revert button, I instantly rolled back all the schema changes and restored the data in those columns. This saved the site from significant downtime, as it would have taken about an hour to finish my code changes and push them to production. Thanks to PlanetScale’s branching and revert features, the website was only down for about 20 seconds.

Thank you, PlanetScale!

May 14, 2024