My main use case for Liquibase is database-as-code, which we use for creating table schemas, maintaining migrations, and ensuring that in production, if rollbacks happen, then it's more controlled than running raw SQL.
I can give you a quick specific example of how I've used Liquibase for migration. Although we have not used it for rollbacks until now, we do use it for managing our scripts during migration.
Liquibase is a database-as-code provider, and that is pretty much how we use it.
The best features Liquibase offers include CI/CD integration, which we really appreciate because we didn't have a lot of issues integrating it into our existing CI pipelines, and the changeset and changelog, which are the source of truth that effectively tell us how the database changes are taking effect.
The CI/CD integration helped my workflow by improving visibility with the changelog and changeset. For the CI part, Maven and Gradle builds are already available, so we just use the Maven plugin and it was pretty straightforward.
There is something called Liquibase Validate as well, which helps with pre-deployment checks. We use the update SQL command for dry-run approvals.
Liquibase has positively impacted my organization by providing a way to manage database migrations instead of maintaining raw SQL, which comes with the issue of not being able to track certain schema updates or new table creations. With Liquibase, you have that history through the changelog and changeset tables, which maintain that history of changes.
Liquibase can be improved by addressing the issue that changelog files could conflict with Git if they're not modularized properly. While we create one file per feature, rollbacks are not magical and require significant consideration, and large diff operations can also be very slow, affecting performance.
We only use MySQL for now, so there's nothing related to any exotic database features, and we're not consuming anything on that side either.
I have been working in my current field for about two years.
