Michael Christofides: Database change management vs performance

This month’s PGSQL Phriday topic is “database change management”, proposed by Dian Fay. While I’ll try to make this topic about performance (as I always do) let me first embark on a quick trip down memory lane. My background in database change management Back in 2010, my first full-time job was at a company called Redgate, who’s flagship product at the time was SQL Compare. To this day, that tool allows folks to quickly compare SQL Server databases, review the differences, and generate a script to make one match the other. Fun fact, since then, an excellent former teammate of mine, Neil Anderson, has now built Postgres Compare. Anyway, back in 2010 when I joined Redgate, they also had a team working on the first version of SQL Source Control, which uses the same engine to sync databases with files in source control and vice versa — pretty cool! I was lucky enough to work with them, and then a few years later, found myself running a wonderful team tasked with building an equivalent tool, but for Oracle. We also built tooling using these engines to enable continuous integration and even continuous deployment of databases. As such, I’ve seen everything from teams with no source control in place for databases, all the way through to folks who had the vast majority of the process automated! What about this decade? And what about Postgres? A lot of the Postgres shops I come across these days use Rails or Django, who already have in-built migrations support. Others use tools such as sqitch, liquibase, or flyway. But honestly, as I mentioned in our podcast episode on version control for databases, I still see a gap between how people manage their databases vs how they manage their application code. As such, if you already have the following in place for your databases, I think you’re ahead of the curve: Version control, with the ability to branch Continuous integration, with unit tests Automated deployment pipeline being the primar[...]