We just released an update to our branching workflow: safe migrations.
Safe migrations give you the option to enable direct DDL on your production branches. Prior to this release, direct DDL was prohibited on all PlanetScale production branches to enable non-blocking schema changes.
Note
Direct DDL refers to the execution of DDL (Data Definition Language) SQL statements directly on your production database. This can lead to table locking and downtime.
How this affects existing databases
If you have an existing production branch, safe migrations have been automatically enabled. Your database has not experienced any changes, and no action is necessary. Going forward, any time you want to enable non-blocking schema changes on a new production branch, you must turn on safe migrations by clicking the "Enable safe migrations" toggle when promoting a branch to production.
Note
Another consequence of disabling safe migrations is that you will no longer be able to use deploy requests, schema reverts, and gated deploys, and you will not receive data loss warnings via the deploy request workflow. For more information, see our safe migrations documentation.
Why did we introduce safe migrations?
PlanetScale went GA on November 16th, 2021. Since then, we’ve continued to innovate by releasing new features that make it easier to manage your database. At our core, we are a customer-driven company, so we love hearing about how people are using our product, as well as feedback about how we can make it better.
We want to ensure we remain the best place to run MySQL, so listening to and acting on user feedback is important to us. This is why we’re constantly releasing improvements and tweaks like safe migrations — to ensure that we're making PlanetScale accessible to all users at all stages of their application development.
Some of our feedback indicated that a small number of users were using workarounds to run direct DDL on their production databases. In some cases, users were utilizing development branches for production workloads, which is never recommended. Stability and availability are the most important product features that PlanetScale offers. This is what led to the development of safe migrations. We want to make sure that customers can use our databases in a highly available configuration via production branches while still maintaining the ability to use their existing tools and processes.
While we still strongly recommend turning on safe migrations for production databases, we ultimately want to give you more power to utilize the workflow that makes sense for you while still providing the tools that allow for safer schema changes, should you decide to use them.
Let’s look at a few of the scenarios where safe migrations may benefit users.
Early development and/or low-traffic applications
If you're in the early "move fast and break things" stage of launching your application, then there's a good chance you're still experimenting with the schema of your database. You're optimizing for speed of change rather than safety. In this case, it makes sense to start your application with safe migrations disabled, allowing you to directly iterate on your schema in production.
Laravel, Rails, and other frameworks with built-in migrations
This update can also benefit developers who have an existing preferred schema migration workflow and would like to keep using it. For frameworks such as Rails and Laravel, it's common for developers to run their schema migrations directly against their production database as part of their deployment process. This workflow is fast and convenient, but does have the potential for downtime as your data size grows.
When your application needs more advanced schema migration tooling, you'll be able to enable safe migrations and integrate it into your deployment process.
Check out the Rails workflow we use in-house for migrating our own database with safe migrations.
WordPress
The last scenario where users may see better support is using PlanetScale with some CMS platforms like WordPress.
In many WordPress setups, you might be used to clicking a button in your WordPress dashboard to add or update a plugin, which may require running DDL on your production database. We've found that not having an option for this workflow is a barrier to entry for some WordPress developers, so you can now turn off safe migrations when you need to update a plugin.
Wrap up
Ultimately, we want to unblock and support our users at every point of their journey. PlanetScale is built to accommodate your application or business from pre-launch all the way to millions and millions of users. Our pricing plans reflect that, and now our workflow options do too.
If you have any questions, we'd love to hear from you. You can reach out to our Support team or find us on Twitter @planetscale.