Ask HN: How does your development team handle database migrations?
I've been really happy with how my current company[0] has been doing migrations and I've seen a couple others do it but it seems like it should be more widespread.<p>Database Schema as Code<p>Instead of writing up and down migrations, you define what the end state should look like. Then the computer will figure out how to get here. This is just how the industry started managing server configurations (Puppet) and infrastructure (Terraform).<p>We use protocol buffers so it was pretty straight forward to have a definition of what our tables should look like. We have a script that figures out what the delta is between two states (either proto files or a db) and can calculate the schema migration SQL (e.g. CREATE TABLE, etc).<p>From there, we run it through a safety check. Any unsafe migration (either for data loss or performance issues e.g. DROP TABLE) requires an extra approval file.<p>There's no real difference between an up migration and a down migration (except that one tends to result in an unsafe migrations). It's calculable at CI time so we can give devs a chance to look at what it's going to do and approve any unsafe migrations. API compatability checks enforce that you need to deprecate before you can drop.<p>DML, that is data changes, are handled via standard check in a sql file and CI will run it before the code deploy and after the schema migration.<p>Alembic is the one other place I've seen this concept (a couple others mentioned this) so it's not new, but surprised I haven't seen it more places.<p>[0] Shameless plug: We're hiring if you're interested in changing how healthcare is paid for, delivered, and experienced. <a href="https://www.devoted.com/about/tech-jobs/" rel="nofollow">https://www.devoted.com/about/tech-jobs/</a>