Liquibase con Spring Boot: Git para tu base de datos

En pocas palabras: Liquibase es la herramienta open source que lleva a tu base de datos el mismo control de versiones que Git le da al código. Con Spring Boot se integra nativa: apuntás la app a un changelog maestro y aplica los cambios pendientes al arrancar, con rollbacks gratis y checksums de integridad.

Si alguna vez tuviste que revertir un cambio de esquema en producción sin acceso directo a la base, sabés lo tenso que es. Liquibase con Spring Boot resuelve eso: le trae a tu base de datos el mismo control de versiones que ya tenés en Git para el código, con rollbacks incluidos en su versión open source. El artículo original de Amanjot Singh en dev.to (2 de septiembre de 2026) lo muestra con SQL Server y ejemplos reales.

Liquibase es una herramienta open source de control de versiones para esquemas de bases de datos que registra cada cambio, verifica su integridad con checksums y permite aplicar o revertir migraciones desde un pipeline de CI/CD. Con Spring Boot se integra de forma nativa: apuntás la aplicación a un changelog maestro y los cambios pendientes se aplican solos al arrancar. Sirve para equipos que manejan varios ambientes (Dev, QA, PreProd) sin tocar la base a mano.

¿Por qué necesitás versionado en la base de datos?

Porque el código tiene Git y la base, históricamente, no tenía nada. Los cambios de esquema se pasaban como scripts SQL sueltos por canales de mensajería o se ejecutaban directo en producción, rezando para que no se rompiera nada. Liquibase le trae a ese caos el mismo historial, ramas y reversiones que ya usás en tu repo.

El ejemplo de la fuente es concreto. Tenés tres ambientes moviéndose a distinto ritmo: PreProd con 5 scripts aplicados (v1.0), QA con 7 (v2.0) y Dev con 10 (v3.0).

• PreProd: scripts 1 al 5, versión 1.0.
• QA: scripts 1 al 7, dos adelante de PreProd.
• Dev: scripts 1 al 10, el patio de juegos del desarrollador.

Ponele que el Product Owner pide sacar una feature de golpe por un cambio de rumbo. Hay que revertir un script específico en QA o PreProd. ¿Y cómo lo hacés sin Liquibase? No podés entrar por SSH ni abrir el Management Studio con credenciales de superusuario, porque la governance empresarial prohíbe el acceso directo de los desarrolladores a esas bases. Tampoco podés adelantar PreProd a producción si todavía no está listo. Ahí Liquibase rescata el flujo: revertís scripts puntuales en cualquier ambiente desde un pipeline automatizado, sin tocar la base con las manos.

¿Cuál es la diferencia entre Liquibase y Flyway?

La diferencia que más pesa es el rollback. Flyway es una alternativa popular, pero su Community Edition no soporta reversiones automáticas: para tener flyway undo tenés que comprar el tier enterprise. Liquibase incluye rollbacks de fábrica en su versión open source. Si tu pipeline exige que cada cambio tenga su script de reversión, esa diferencia define la elección.

Eso sí: Flyway es más simple de arrancar si tu proyecto es chico y no te importan los rollbacks. Para entornos enterprise con auditoría, Liquibase gana por goleada.

¿Por qué no correr scripts SQL directo en producción?

Porque en un entorno enterprise ese atajo te explota en la cara. En un proyecto personal o de bajo riesgo, entrar y modificar tablas a mano zafa. En una empresa, no.

• Seguridad y auditoría: darle acceso DDL a cada desarrollador crea riesgos de cumplimiento con SOC2, HIPAA e ISO.
• Error humano: las queries manuales no tienen verificación por checksum, así que los ambientes se desvían entre sí sin que nadie lo note.
• Automatización del pipeline: las empresas exigen que cada script estándar tenga su script de rollback, para que DevOps ejecute los cambios de forma segura.

Como Liquibase da rollbacks open source, cada cambio se prueba, se aplica y se revierte en CI/CD sin sorpresas. Para más detalles técnicos, mirá dentro de tu pipeline de integración continua.

¿Cómo rastrea Liquibase los cambios por debajo?

Con dos tablas que crea y mantiene solo. Cuando Liquibase corre contra una base, escribe en DATABASECHANGELOG y usa DATABASECHANGELOGLOCK como candado.

La primera registra cada changeset aplicado: id, autor, nombre de archivo, fecha de ejecución y el famoso md5sum. Ese checksum es la clave de la “auditoría” real, porque si alguien edita un script que ya se aplicó, el hash no coincide y Liquibase frena. La segunda tabla es un booleano que evita que dos pods de Kubernetes o dos instancias de microservicio apliquen migraciones a la vez y se pisen.

Cómo configurar Liquibase con Spring Boot y SQL Server

La integración con Spring Boot es directa: agregás las dependencias, apuntás application.yml al changelog maestro y Boot aplica los scripts pendientes al arrancar. Estos son los pasos que muestra la fuente, con SQL Server como motor.

Estructura de archivos recomendada

El layout probado en producción separa configuración de scripts. Un master-changelog.xml como punto de entrada, una carpeta environments/ con DEV.properties, QA.properties y PREPROD.properties, y carpetas por release (release-1.0/, release-2.0/) con cada script forward y su gemelo de rollback. Esa modularidad mantiene el repo navegable trimestre a trimestre.

application.yml y el master changelog

En application.yml apuntás a classpath:db/changelog/db.changelog-master.xml y definís el contexto activo con ${spring.profiles.active}, así el contexto de Liquibase queda atado al perfil de Spring. Dentro del changelog maestro, cada <changeSet> referencia su archivo SQL con relativeToChangelogFile=true y su rollback correspondiente. Además podés etiquetar la versión de release con <tag> en la tabla DATABASECHANGELOG.

Filtrar por contexto según el ambiente

Acá viene lo bueno: en vez de meter IF/ELSE en el SQL, anotás el changeset con un atributo de contexto. Al correr Liquibase pasás el ambiente actual por archivo de propiedades o por CLI:

liquibase --defaults-file=environments/QA.properties --contexts=QA update

Así sembrar datos de prueba corre solo en Dev y QA, y se saltea en PreProd y Producción. Esto vale tanto si tu base vive en un servidor propio como en la infraestructura de donweb.com para tus ambientes cloud.

¿Cómo escribir rollbacks en SQL para cada migración?

Con anotaciones de SQL formateado, escribís SQL puro y Liquibase igual lo trackea. Cada archivo arranca con --liquibase formatted sql y define su changeset y su reversión en la misma pieza.

--liquibase formatted sql
--changeset aman:001-create-orders
CREATE TABLE orders (...);
--rollback DROP TABLE orders;

Para scripts atados a un ambiente, sumás el contexto en la misma línea del changeset: En al automatizar migraciones de base de datos profundizamos sobre esto.

--liquibase formatted sql
--changeset aman:002-cargar-datos-qa context:dev,qa
INSERT INTO orders (...) VALUES (...);
--rollback DELETE FROM orders WHERE order_number IN ('ORD-TEST-001', 'ORD-TEST-002');

Cuando arranca Boot, aplica todos los scripts pendientes. Y si más adelante tenés que revertir desde el pipeline, tirás mvn liquibase:rollback para deshacer el último changeset, o revertís a un tag de versión específico.

Errores comunes al usar Liquibase

• Editar un changeset ya aplicado: si cambiás un script que ya corrió, el md5sum no coincide y Liquibase aborta. La corrección es crear un changeset nuevo, nunca tocar uno viejo.
• Olvidar el script de rollback: escribir el forward sin su reversión rompe la promesa de CI/CD seguro. Cada cambio necesita su --rollback antes de mergear.
• No usar el lock en microservicios: desactivar DATABASECHANGELOGLOCK en un despliegue multi-pod hace que dos instancias apliquen la misma migración y se corrompa el estado. Dejalo activo siempre.
• Confundir contexto con label: usar context para versionar y no para segmentar ambientes termina en scripts de test filtrándose a producción. El contexto es para el dónde corre, no para el qué versión es.

Preguntas Frecuentes

¿Cómo usar Liquibase con Spring Boot?

Agregás la dependencia de Liquibase (y el driver, por ejemplo com.microsoft.sqlserver) al pom.xml, configurás en application.yml la ruta del changelog maestro con classpath:db/changelog/db.changelog-master.xml y el contexto activo. Al arrancar la aplicación, Spring Boot aplica de forma automática todos los changesets pendientes.

¿Cuál es la diferencia entre Liquibase y Flyway?

Liquibase incluye rollbacks automáticos en su versión open source; Flyway Community no soporta flyway undo y exige comprar la edición enterprise para revertir migraciones. Liquibase también acepta changelogs en XML, YAML, JSON o SQL, mientras que Flyway trabaja sobre todo con SQL.

¿Cómo hacer rollback de migraciones en Liquibase?

Definís el rollback junto al changeset (con --rollback en SQL formateado o un bloque en XML) y lo disparás desde el pipeline con mvn liquibase:rollback. Podés revertir el último changeset aplicado o volver a un tag de versión concreto que hayas etiquetado en la tabla DATABASECHANGELOG.

¿Cómo versionar cambios de base de datos automáticamente?

Liquibase mantiene la tabla DATABASECHANGELOG, que registra cada changeset con id, autor, archivo, fecha y md5sum. Cada vez que corre, compara los changesets del changelog contra esa tabla y aplica solo los pendientes, así el versionado queda automático y auditable.

¿Cómo configurar Liquibase para diferentes ambientes?

Usás el atributo context en cada changeset (por ejemplo context:dev,qa) y pasás el ambiente activo al ejecutar: liquibase --defaults-file=environments/QA.properties --contexts=QA update. Así los scripts de datos de prueba corren solo donde corresponde y se saltean en PreProd o Producción.

Conclusión

Manejar migraciones de base no debería ser caminar por la cuerda floja sin red. Con Liquibase le das a tu esquema el mismo historial, checksums y reversiones que ya tenés en el código, y con Spring Boot todo eso arranca solo al levantar la app. Si estás eligiendo herramienta y te importan los rollbacks sin pagar licencia, Liquibase es la opción más sólida hoy.

El próximo paso concreto: armá la estructura de carpetas por release, escribí cada script con su --rollback desde el día uno y atá el contexto de Liquibase al perfil de Spring. Con eso, revertir una feature cancelada deja de ser un drama de acceso a producción y pasa a ser un comando en tu pipeline.

Fuentes

• Liquibase: Git for Databases (with Spring Boot) – artículo original de Amanjot Singh en dev.to (2026)
• Documentación oficial de Liquibase – referencia de changelogs, contextos y rollbacks
• Spring Boot Reference – integración con Liquibase