We Don't Need Migrations Anymore

there are only two ways to change your database [Music] databases are hard I don't think that's Up For Debate but what if I told you one of the core pieces of how we've done databases for the last three decades now is an anti-pattern and should be avoided what the hell am I talking about migrations specifically migration files they are encouraging bad patterns and just setting you up for failure and I'm going to talk a bit about why today so what is a database migration specifically a migration file in most systems things like active record in the Ruby world or even Prisma over an rt3 land a migration file is a file that's usually named with a time stamp and some key name like added user table removed username field renamed whatever and those migration files are actual SQL that is run against your SQL database so if you have 15 migrations that were made in order over time one adds a field one removes a field one adds a model one links that model to another model then one destroys the link Whenever you set up your database it's just going to go through each of those migrations and run all of them one after another after another to get your database into the right State the write State being what the main branch in your code base currently understands is production sounds great but sadly there's a lot of problems with this model first off it only knows as much as is in the history for the branch you're currently on so if you and I are both working on different migrations at the same time we might end up merging those at different times but I may have made my migration before you made yours and since those are different files they're not going to conflict and now I have SQL that might do something really stupid that seemed like it was doing something really smart when I wrote it it is so easy for migrations to fall out of sync not because they're out of sync in the code but because they're out of sync in the git commit merge history in order and managing all of this is obnoxious if you haven't dealt with this before then you're not working with migration files at scale with multiple Engineers contributing to the database migration files don't work great in git in two ways first off as I mentioned before in parallel migration files can get messy and with Git you already have your version history too if you theoretically had a file that represented the exact state of your database and you wanted all of the wastes changed that's your git history your git history is your migration history if you really want that but chances are you don't what you want is a database that is perfectly synchronized with the current state of the code there are only two ways to change your database on one hand you can change your database in a way that is fully backwards and forwards compatible and safe to roll out and roll back whenever or you can have down time there is no in between your options are full backwards and forwards compatibility or downtime what do I mean by this let's say we want to rename a field for user right now it's name but we want to change it to full name if we were to make a migration that changes the field from name to full name and we apply that change a little bit before our code ships that reads full name then now there is code in production that expects the field name which doesn't exist which will error or we can ship the code first but now it's expecting the field full name which hasn't been changed in the database yet a migration that renames a field from name to full name inherently has downtime baked into it the only way to safely make a change like this is to have two Fields one that has the old name name one that has the new name this case full name and when you have these two different fields inside of your database you can start writing to the new one backfill it for the old values and then and only then when you have confirmed that there are no clients that expect the old name still then you can drop it but that is three SQL queries you have to run not one for that migration the first query is one that adds the new field the second one is one that backfills the Old Fields value to the new field and the third one is when you can finally drop that old field if you're not doing migrations that way then you have downtime I'm not saying down time is inherently bad I'm saying you have it and should be considerate of that as you make decisions when I want to have a database in production that perfectly matches our code and can have changes made to it we're synchronizing a schema we're not migrating a database what we use at ping is planet scale and Planet scale has a branch feature kind of similar to making branches in code where it lets you add and remove fields to a schema and when you hit merge it will apply Those ads and removes to your main database by making it just adding and removing of fields and models they prevent us from making changes that aren't backwards compatible and writing migrations that risk real downtime migrations don't have a good story for most of the problems you'll run into when you're building databases and if you can move away from that model towards a proper backwards and forwards compatible model where you can deploy and revert changes with confidence without problems then your database will finally start to get a little less scary but until then every time you make a new migration file you're risking big problems because you don't actually know the state of the database underneath that migration because somebody could have sniped it out from under you someone could emerge something else before you and God please do not automatically run them if you do still use migrations because as I said a merge won't have a conflict but your sequel might still be conflicting I was surprised at how common migration files still are when we have had so much better an experience since we dropped them in favor of just using a schema and in the Prisma case we just DB push and it works great hope this was helpful let me know what you guys think in the comments take a look at the video that's being recommended right there should be a good one YouTube thinks it is and make sure you're subbed if you're not for some reason appreciate you a bunch see in the next one

Channel: Theo - t3․gg

Views: 57,844

Keywords: web development, full stack, typescript, javascript, react, programming, programmer, theo, t3 stack, t3, t3.gg, t3dotgg

Id: jeWrbAiA1D0

Length: 6min 21sec (381 seconds)

Published: Mon Jan 23 2023