Supabase Local Dev: migrations, branching, and observability

a few months ago one of customers migrated away from supabase and they wrote a blog post about it. That blog post appeared here[0] on hacker news. many of the issues they encountered were related to local development. we made several promises to improve based on that feedback and the various comments in the HN thread

today’s launch delivers on many of those promises. We’ve added better support for database migrations, seeding, backups, debugging, and documentation.

we have a lot of work ahead, this is just the first step. our next major step forward is “branching”, which we’re rolling out today for development partners and alpha testers.

we’ve coupled the branching functionality to GitHub for now. whenever you create a new PR we launch a new instance, run the database migrations in your version control, and seed the database for reproducible test environments. we’re using Firecracker[1] for every preview environment. This environment automatically pauses when it’s not in use. we’re seeing some very impressive startup times, even though we’re stuffing a lot of services inside the VM. We looked at making full-production clones but decided against that for now until we have a robust strategy for anonymizing production data and mocking out calls to external services. Ultimately we want to offer both options, it’s just easier and safer to start with seed data.

since supabase offers a few services beyond the Postgres database, we still have a few questions to work through with our alpha testers. for example, we also store images/videos/files for our customers. Do these need to be anonymized in preview environments? we don’t have all the answers yet, but we’re moving in the right direction. As hard as it was to have a customer migrate away so publicly, I’m proud of the work the team have done to improve on feedback

[0] https://news.ycombinator.com/item?id=36006018

[1] Firecracker: https://firecracker-microvm.github.io/