Database migration or schema evolution is inevitable in any long-lasting project. While NoSQL databases give more leeway, relational databases are pretty rigid regarding schema evolution. Hence, having a suitable tool [...]
I am always surprised to learn something new whenever I talk to a member of the open-source community. No matter how much I think I have heard of every use case there is for Liquibase (and database change management in general), I always hear something that makes this space still feel new. There’s always something left to discover.
Today, that new something is the problem of how to perform large batches of changes with SQL ALTER TABLE statements. No problem you say? Okay, but this ALTER needs to happen in production. Still not worried? Well, let’s say you have millions of rows, and because you’re so successful, you have many transactions happening per minute (maybe even per second). Yeah…now we are talking. You can’t alter the table because you can’t afford to lock that table for the …[Read more]
Recently, I helped a client that was having issues with deployments causing locking in their production databases. At a high level, the two key components used in the environment were:
At a high level, they currently used a CLI call to Liquibase as a sub-task within a larger deployment task. The goal of this engagement was to modify that sub-task to run Liquibase in a non-blocking fashion as opposed to the default that just runs native ALTERS against the database.
As I wasn’t very familiar with Liquibase, I took this opportunity to learn more about it and it seems like a very valuable tool. Essentially, it does the following:
- Adds two version control tables to …