I use good old fashioned numbered SQL scripts. 01_foo.sql 02_bar.sql 03_baz.sql In my local dev environment, I have a DB backup representing the current state

I use good old fashioned numbered SQL scripts. 01_foo.sql 02_bar.sql 03_baz.sql In my local dev environment, I have a DB backup representing the current state of production. This is the starting point SQL scripts must be applied to. A deployment script restores this DB, then applies the SQL scripts against it. The entire deployment process takes about 2 seconds even with many gigs of data in the DB backup. Sometimes I'll include an extra "dummy data" script applied at the end. My local environment, Test, and Production are deployed in almost exactly the same way. A few extra actions are done for Production of course. And Production is not restored as that would loose data. Local dev is optimized for a speedy restore/deploy. Developers always want to treat the DB as if it's code. But it's not. It's a blob of valuable state that must be protected from corruption. You apply patches to that blob of state. The order patches occur matters. There's no "re-build" like in pure code.