It doesn't have to be, but tooling and initial design matters a lot. I've done a lot of significant migrations this year (changing schemas of hundreds of millio

It doesn't have to be, but tooling and initial design matters a lot. I've done a lot of significant migrations this year (changing schemas of hundreds of millions of rows in postgres) in a downtime-free, non-breaking way, but there were two big pieces: - separate internal schemas from external ones, so you can change the internals while maintaining your interface contract. Your database has an API whether you realize it or not, so treat it like one. I literally have schemas like "api" and "api_v2". - use a great migration tool. I've been using sqitch, which I love because it encourages me to think about how to _verify_ each migration does the correct thing. Tie that into CI/CD in a nice way and DB migrations are no longer scary That probably downplays the effort; as someone who's never done DBA work before, I've had to learn a lot about PL/pgSQL, transaction isolation levels, role management, etc. for the first time. I think I'm better for it, though, and I've quite enjoyed going beyond query-writing.