Liquibase dejó Apache 2.0: qué cambia en 2026

En pocas palabras: Liquibase Community 5.0 (30/09/2025) pasó de Apache 2.0 a Functional Source License 1.1, generando el issue #43391 priority/blocker en Keycloak, aún abierto al 14/09/2026. Para Microsoft SQL Server, Flyway (Apache 2.0) y Atlas (Apache 2.0, drift detection desde $9/dev/mes) quedan como alternativas sin restricción de licencia.

Liquibase Community 5.0 salió el 30 de septiembre de 2025 bajo Functional Source License 1.1, dejando atrás Apache 2.0 después de años como opción de referencia para migraciones multi-motor. El cambio disparó un issue priority/blocker en Keycloak que sigue abierto hoy, 14 de septiembre de 2026, y reordenó qué herramientas de migración de base de datos conviene evaluar.

Las herramientas de migración de bases de datos versionan y aplican cambios de esquema (tablas, columnas, índices) sin correr SQL a mano contra producción. Da igual si tu motor es Microsoft SQL Server, Postgres o MySQL: elegir entre las distintas herramientas de migración de bases de datos de Microsoft disponibles hoy define si un ALTER TABLE hecho a mano se detecta al toque o se descubre por accidente semanas después.

¿Qué licencia usa Liquibase desde la versión 5.0?

Desde el 30 de septiembre de 2025, Liquibase Community se distribuye bajo Functional Source License 1.1, con el sufijo ALv2 (FSL-1.1-ALv2), y no bajo Apache 2.0 como todas las versiones anteriores. Podés usarla, correrla en producción y forkearla gratis, pero cada release individual queda restringido durante dos años antes de convertirse en Apache 2.0 de forma automática.

La letra chica importa. Según los términos publicados por Liquibase, el uso permitido cubre todo lo que no sea “Competing Use”: ofrecer el software a terceros como sustituto comercial del propio Liquibase o de algo funcionalmente parecido. Uso interno, educación no comercial, investigación no comercial y servicios profesionales entran en la lista de usos permitidos. Lo que no entra es armar un producto competidor con el código.

¿Es esto open source? No, aunque se parezca. FSL es source-available: el código está ahí, lo podés leer y modificar, pero no cumple la definición de la Open Source Initiative porque restringe un uso específico durante un plazo fijo. La versión 5.0.4, lanzada el 20 de agosto de 2026, ya sale directamente bajo este esquema.

¿Por qué Keycloak y otros proyectos abrieron un issue por el cambio de licencia?

Keycloak abrió el issue 43391 el 13 de octubre de 2025, etiquetado priority/blocker, porque el proyecto forma parte de CNCF y esa fundación no acepta licencias source-available en sus componentes. La nota del issue lo dice sin vueltas: “CNCF does not permit source available licenses”.

Las opciones que el equipo puso sobre la mesa fueron tres. Reemplazar Liquibase por otro componente. Congelar la dependencia en la última versión con licencia Apache 2.0. O forkear el proyecto y mantenerlo por su cuenta.

Ninguna es gratis en términos de trabajo. ¿Y qué pasó desde entonces? Nada, en el sentido de que el issue sigue abierto al 14 de septiembre de 2026, casi un año después de abrirse. Eso ya dice algo sobre el esfuerzo que implica resolver este tipo de decisión cuando un proyecto de la magnitud de Keycloak la tiene que tomar en serio: no es un simple bump de versión, es repensar una dependencia estructural del sistema de build.

¿Cómo afecta el cambio de licencia a la elección de herramientas de migración de bases de datos de Microsoft?

Si tu organización tiene una política de licencias aprobadas, o si redistribuís la herramienta dentro de un producto, la licencia cierra la comparación antes de mirar features. No importa cuán bueno sea el soporte de rollback de Liquibase si FSL no pasa el comité de compliance.

Acá entra un dato que cambia el peso de la decisión: la mayoría de los equipos corre un solo motor, no cinco. El Stack Overflow Developer Survey 2025 ubicó a PostgreSQL en 58,2% de los desarrolladores profesionales, MySQL en 39,6% y Microsoft SQL Server en 30,9%. El soporte multi-engine, que es el argumento de venta central de Liquibase con más de 65 bases de datos soportadas, es justo la función que la mayoría de los equipos nunca va a tocar.

Ejemplo hipotético: pensemos en un equipo con SQL Server como único motor, sin necesidad real de portabilidad entre bases, que está evaluando Liquibase más por costumbre que por necesidad concreta. Ese equipo termina pagando —en complejidad de configuración, no necesariamente en plata— por una abstracción multi-motor que jamás va a usar. Si además tiene una política de licencias que excluye FSL, la decisión ya está tomada antes de comparar nada más: el motor único empuja hacia Flyway, y la política de licencias lo confirma.

¿Qué alternativas hay a Liquibase después del cambio de licencia?

Las alternativas se dividen en dos familias: herramientas versionadas, parecidas a Liquibase en el modelo, y herramientas declarativas, que cambian cómo trabajás con las migraciones.

Flyway, la opción versionada más simple

Flyway ejecuta archivos SQL numerados y los registra en una tabla propia, sin DSL ni capas adicionales. Sigue bajo Apache 2.0, con la versión 13.6.0 lanzada el 10 de septiembre de 2026. El drift detection y el undo generation quedan reservados a Enterprise, y el tier Teams tiene un límite documentado de 100 esquemas.

Atlas, la opción declarativa

Atlas describe el esquema deseado y genera el plan de migración comparándolo contra la base real. Eso convierte el chequeo de drift en algo normal del flujo de trabajo, no en un upsell. Según la página de precios de Atlas, el plan Pro arranca en 9 USD por desarrollador al mes, sobre una base Apache 2.0, con la versión 1.3.0 publicada el 2 de agosto de 2026.

Bytebase, la capa de gobierno

Bytebase no reemplaza al motor de migraciones, lo envuelve con una cola de revisión, flujo de aprobación y auditoría. El core es MIT, pero el tier gratuito de su plan de precios tiene un tope de 20 usuarios. Versión 3.22.1, del 10 de septiembre de 2026.

Prisma Migrate y Alembic, integradas al ORM

Prisma Migrate genera SQL editable a partir del diff entre el schema y la base. Ojo con esto: según el estado de releases de Prisma, ORM 8 todavía es release candidate, con disponibilidad general esperada para octubre de 2026, y $extends, varios nested writes y los códigos de error P2002 no están listos todavía. Conviene quedarte en la línea 7 (7.10.0, del 25 de agosto). Alembic, escrita por el autor de SQLAlchemy, genera revisiones en Python que podés editar a mano. MIT, versión 1.20.0 del 11 de septiembre de 2026.

Herramienta	Modelo	Precio de entrada	Detección de drift	Licencia
Flyway	SQL versionado	Community gratis	Solo Enterprise	Apache 2.0
Liquibase	Changelog versionado	Community gratis	Tier pago	FSL-1.1-ALv2
Atlas	Declarativo	9 USD/dev/mes	Incluida	Apache 2.0
Bytebase	Gobierno / cola de revisión	Gratis (tope 20 usuarios)	Incluida	MIT (core)
Prisma Migrate	Integrada al ORM	Gratis	No	Apache 2.0
Alembic	Integrada al ORM	Gratis	No	MIT

¿Cómo detectar drift en el esquema de base de datos sin depender del tier pago de Liquibase?

Corriendo un chequeo declarativo contra la base real en lugar de confiar en la tabla de historial de migraciones. Las herramientas versionadas, como Flyway, Liquibase y Alembic, solo saben si los scripts que ellas mismas aplicaron corrieron bien. Cualquier cambio que llegó por otro camino les es invisible.

Ejemplo hipotético: imaginemos que aplicás dos migraciones un lunes, y el martes a las 2am alguien entra al servidor y corre un ALTER TABLE a mano para agregar una columna urgente. Al otro día le preguntás a cada herramienta cómo está el esquema. Un tool versionado te va a decir “2 de 2 migraciones aplicadas, todo en orden”, porque esa es la única pregunta que sabe responder: si los archivos que conoce corrieron bien. Un tool declarativo como Atlas, en cambio, compara el esquema deseado contra el real y encuentra la columna nueva que no figura en ningún archivo de migración. Las dos herramientas corrieron contra la misma base de datos esa mañana. Solo una se dio cuenta de que algo cambió por fuera del proceso.

Ese es el motivo por el que la detección de drift es la función que más vale pagar en esta categoría, y también por el que casi todos los proveedores la esconden atrás del tier pago. Atlas es la excepción porque el diffing es parte de cómo funciona, no un agregado. Si administrás vos mismo la infraestructura —on-prem o en un VPS— antes de firmar cualquier renovación conviene correr ese chequeo en un entorno de staging real y fijarse qué devuelve cada herramienta. La mayoría de los tiers gratuitos no va a encontrar nada, y ese silencio no significa que todo esté bien.

¿Qué herramienta conviene según el perfil del equipo?

Más que comparar features una por una, ayuda partir de tres preguntas concretas, en este orden:

• ¿Cuántos motores de base de datos usás en serio? Si la respuesta es uno, el soporte multi-motor de Liquibase (65+ bases) es una capacidad que pagás en complejidad y nunca aprovechás. Flyway o Atlas alcanzan.
• ¿Tu política de licencias permite FSL? Si no, Liquibase queda descartado antes de mirar el resto de la tabla, sin importar cuánto te convenza el rollback nativo.
• ¿Ya usás un ORM con migrador propio (Prisma, SQLAlchemy)? Sumar una segunda herramienta de migración por fuera del ORM crea dos fuentes de verdad para un mismo esquema. Conviene quedarse con el migrador que ya tenés antes de sumar otro.
• ¿Varias personas pueden tocar producción directamente? Si la respuesta es sí, una cola de aprobación tipo Bytebase importa más que el formato de archivo de migración que uses.

Con esas cuatro respuestas, la mayoría de los casos se resuelve solo: equipo chico con un motor y sin necesidad de auditoría, Flyway Community alcanza y sobra. Incidentes recurrentes por cambios de esquema mal controlados, Atlas justifica el costo por developer. Auditoría y compliance como prioridad, Bytebase si la política de licencias excluye FSL, Liquibase Secure si la permite.

Errores comunes al elegir herramienta de migración en 2026

• Confundir “gratis en producción” con “open source”. FSL permite correr Liquibase sin costo, pero no es una licencia aprobada por la OSI. Si tu política corporativa exige open source estricto, FSL no la cumple aunque el software sea gratuito.
• Elegir por soporte multi-motor sin necesitarlo. Con Postgres, MySQL y SQL Server cubriendo la enorme mayoría de los equipos por separado según el Stack Overflow Developer Survey 2025, pagar la complejidad de una herramienta pensada para 65 motores cuando usás uno solo es cargar peso de más.
• No testear el drift detection antes de comprar. Es fácil asumir que “algo debe estar chequeando esto” hasta que corrés el experimento del ALTER TABLE manual y descubrís que tu herramienta actual no se entera de nada.
• Tratar el freeze en la última versión Apache como solución permanente. Keycloak lo puso como opción temporal, no como estrategia de largo plazo: congelar versiones te deja sin actualizaciones de seguridad.

Preguntas Frecuentes

¿Por qué Liquibase cambió de licencia?

Liquibase Inc. pasó su Community edition de Apache 2.0 a Functional Source License 1.1 el 30 de septiembre de 2025, según los términos publicados en su propio sitio. El objetivo declarado por la empresa fue “fortalecer Liquibase Community para el futuro”, limitando durante dos años el uso competitivo del código antes de que cada release vuelva a Apache 2.0.

¿Liquibase sigue siendo gratis después del cambio de licencia?

Sí, Liquibase Community sigue siendo gratis para usar, modificar y correr en producción bajo FSL 1.1. Lo que cambió no es el precio, es el tipo de licencia: ya no es open source aprobado por la OSI, aunque el código esté disponible y se pueda forkear.

¿Qué diferencia hay entre Flyway, Liquibase y Atlas?

Flyway y Liquibase son versionadas: ejecutan un listado ordenado de scripts y registran cuáles corrieron. Atlas es declarativa: compara el esquema que vos definís contra el estado real de la base y genera el plan de cambios. Esa diferencia es la que determina si detectan drift o no.

¿Qué es la detección de drift en migraciones de base de datos?

La detección de drift es el chequeo que compara el esquema real de la base contra lo que la herramienta de migración cree que aplicó. Detecta cambios hechos por fuera del proceso normal, como un ALTER TABLE corrido a mano, algo que las herramientas puramente versionadas no pueden ver por diseño.

¿Qué alternativas open source hay a Liquibase en 2026?

Flyway (Apache 2.0), Atlas (Apache 2.0), Bytebase (MIT en su core) y Alembic (MIT) siguen bajo licencias permisivas tradicionales en 2026. Todas están activas, con releases recientes entre agosto y septiembre de 2026, y ninguna pasó por un cambio de licencia como el de Liquibase.

Conclusión

Lo que cambió en esta categoría durante 2026 no fue una función nueva, fue una licencia. Liquibase dejando Apache 2.0 sacó de la mesa la respuesta obvia para migraciones multi-motor open source, y lo que queda son herramientas de propósito único como Flyway, o herramientas declarativas como Atlas que te piden cambiar cómo trabajás.

Si estás por renovar algo en esta categoría, hacete una pregunta simple: si alguien altera producción a mano esta noche, ¿cuál de tus herramientas te avisa mañana a la mañana? Contá cuántos motores de base de datos usás en serio. Revisá la política de licencias antes que la lista de features. Y probá el rollback antes de necesitarlo, porque en Flyway es pago y en Liquibase y Alembic es gratis, y esa diferencia solo se nota cuando ya es tarde.

Fuentes

• Liquibase – Functional Source License 1.1, términos oficiales
• Database Migration Tools in 2026: What Changed After Liquibase Left Apache 2.0
• Keycloak – Issue #43391: cambio de licencia de Liquibase
• Atlas – Planes y precios
• Stack Overflow Developer Survey 2025 – Tecnología