Atlas – Terraform but for Database Migrations

Re:Atlas – Terraform but for Database Migrations by throwdbaaway on Saturday January 22, 2022 @06:34PM (#30041959)

I thought the established wisdom is to make schema migration compatible with both the old app and the new app, whenever it is possible? E.g. you can safely add a nullable column, and it shouldn't trip up the old app nor the new app, unless you are using some crappy ORM that does "SELECT *", or you are on an older MySQL version that may take hours/days/weeks to rewrite the whole table just to add a nullable column.

https://github.com/fabianlindfors/reshape, on HN front page a couple weeks ago, has some nice tricks to help with the incompatible cases.

[ Parent | on HN ]

Re:Atlas – Terraform but for Database Migrations by jrockway on Saturday January 22, 2022 @06:47PM (#30042066)

I think that's the established common wisdom, but it's not well-enforced by anything, and it's not innate. Everyone learns this the hard way once.

[ Parent | on HN ]

Re:Atlas – Terraform but for Database Migrations by jokethrowaway on Sunday January 23, 2022 @03:49AM (#30044665)

I would say a fair share of companies bent on following good practices do that. It's not all of them or not even the majority but I haven't seen cowboys migrations in 10+ years

[ Parent | on HN ]

Re:Atlas – Terraform but for Database Migrations by throwdbaaway on Saturday January 22, 2022 @06:51PM (#30042100)

Right, I did have to learn this the hard way back in 2014.

[ Parent | on HN ]

Re:Atlas – Terraform but for Database Migrations by kodah on Saturday January 22, 2022 @08:12PM (#30042650)

You can get by on that "wisdom" for a while, but eventually your DB will garner a significant size and performance impact as a result. That said, even on very active products that takes a while, so there's probably something to blending the idea of one large migration every so often and only making schema compatible changes along the way.

[ Parent | on HN ]