Sqldef: herramienta de gestión de esquemas idempotente para MySQL, PostgreSQL y SQLite

• Herramienta basada en CLI para gestionar migraciones de bases de datos comparando las diferencias (diff) entre esquemas SQL
• Permite gestionar esquemas de RDBMS usando la sintaxis SQL DDL habitual
• Compatible con bases de datos principales como MySQL, MariaDB, TiDB, PostgreSQL, SQL Server y SQLite3
• En el sitio web se puede probar la comparación de esquemas y la generación de DDL mediante una demo en línea impulsada por una compilación en WebAssembly
• Permite gestionar cambios en la base de datos de forma idempotente, lo que resulta útil para una sincronización de esquemas estable

---

Resumen de sqldef

• sqldef es una herramienta CLI que compara (diff) dos esquemas SQL, analiza las diferencias y, con base en ello, genera sentencias DDL
  • Los usuarios pueden comparar el esquema actual con el esquema objetivo para obtener automáticamente los cambios necesarios
  • Es posible realizar migraciones usando directamente la sintaxis SQL DDL común
• Las bases de datos compatibles indicadas son MySQL, MariaDB, TiDB, PostgreSQL, SQL Server y SQLite3

Funciones de la demo en línea

• El sitio web ofrece una Online Demo para revisar visualmente los cambios de esquema
  • La opción “Enable DROP” permite controlar si se incluyen o no comandos de eliminación
  • La sección “Up (current → desired)” muestra ejemplos de DDL como agregar nuevas columnas, crear índices y añadir restricciones
  • La sección “Down (desired → current)” ofrece ejemplos de cambios en sentido inverso, como eliminar restricciones

Cómo funciona

• La demo en línea usa una compilación de sqldef en WebAssembly para realizar en el navegador la comparación (diff) entre esquemas SQL
  • Calcula las diferencias entre dos esquemas y genera automáticamente las sentencias DDL necesarias como resultado
  • Es posible consultar el código fuente de la compilación WebAssembly mediante el enlace al repositorio de GitHub

[GN⁺]

Comentarios en Hacker News

• Si quieres una cobertura más completa para Postgres, vale la pena echarle un vistazo a pgschema, que yo hice
  El verano pasado pensé que ya estaba bastante terminado, pero al resolver más de 100 issues reportados por usuarios durante 6 meses, me di cuenta de lo ingenuo que era

  • Está realmente genial. Vamos a hacer una PoC con mi equipo
    Me pregunto si también soporta revisar inconsistencias entre varios clústeres de bases de datos
  • Me recuerda a Migra
  • Se ve bueno para migraciones de esquema, pero me pregunto cómo maneja update/insert cuando hace falta mover datos reales
  • pg_roll de Xata también puede ser una alternativa a considerar

• Lo probé con SQLite, y en migraciones complicadas donde se agregan restricciones de clave foránea a tablas existentes, genera SQL inválido
  Por ejemplo, una sentencia como ALTER TABLE books ADD CONSTRAINT fk_books_author FOREIGN KEY (author_id) REFERENCES authors (id) no está permitida en SQLite
  Consulta la documentación relacionada: SQLite ALTER TABLE

  • Entonces, ¿al final para agregar una clave foránea hay que eliminar la columna y volver a agregarla?

• Yo uso Atlas
  Tanto el enfoque basado en migraciones como el basado en esquema tienen pros y contras, así que uso ambos dentro de un mismo proyecto
  El enfoque basado en esquema acelera el desarrollo, y el basado en migraciones permite despliegues con más confianza

  • Soy Ariel, del equipo de Atlas. Es común usar el modo declarativo en local y el modo versionado en entornos reales
    Como Atlas genera migraciones automáticamente en los PR, la mayoría de los desarrolladores no lidian directamente con el flujo versionado
    Documentación relacionada: Declarative vs Versioned Workflows, Atlas Action
  • Yo también estaba viendo sqldef y otras alternativas, y fue así como encontré Atlas
    Me gustó que soporta un migration flow explícito. Quiero saber exactamente qué cambios se van a aplicar antes del despliegue real

• Me pregunto si hay alguna buena herramienta que soporte migraciones en segundo plano
  Por ejemplo, agregar una columna temporal nullable a una tabla grande, dejar que el código nuevo empiece a escribir datos ahí, luego completar los datos existentes por lotes en segundo plano y al final cambiarla a non-nullable
  Estaría bien tener una herramienta que permitiera expresar esos cambios procedimentales de forma declarativa y revisarlos/probarlos junto con el código
  Ahora mismo, la mayoría de las veces eso se resuelve con scripts temporales e instrucciones manuales de despliegue

  • Yo suelo escribir las migraciones de esquema a mano, pero principalmente uso grate
    Es fácil de configurar en entornos de desarrollo, y hay ejemplos como FastEndpoints-SqlJobQueues

• Esta herramienta está muy buena
  Gracias a eso puedo abandonar mi proyecto hobby en el que iba a hacer lo mismo
  En su lugar, voy a arrancar otro proyecto nuevo que ya se ha resuelto unas 100 veces, como una herramienta simple para monitorear logs de systemd y mandar errores por email

• Me alegró ver que no es otro migration manager más, sino una herramienta pequeña y útil
  Se siente como una buena forma de compensar las debilidades de SQL. También me hace pensar que ojalá fuera declarativo como el DDL de Spanner
  En Postgres trato de mantener los scripts de esquema idempotentes. Empiezo con CREATE TABLE IF NOT EXISTS, y cuando agrego columnas nuevas dejo los ALTER por separado
  Pero con el tiempo los scripts se vuelven complejos, y cuando todo se estabiliza limpio las sentencias ALTER
  Si alguna vez hubiera que restaurar un backup viejo, una herramienta así podría ayudar a ponerse al día de compatibilidad rápidamente

• Me pregunto cómo se compara con Entity Framework o sqitch/liquibase
  Entiendo el enfoque declarativo, pero en DBs grandes de producción las migraciones no son simplemente declarativas
  Un administrador de esquemas ideal debería entender el costo de las consultas y las estrategias para minimizar downtime
  Agregar columnas o cambiar índices puede provocar un escaneo completo de la tabla

  • El problema mayor es que los propios datos pueden ser parte de la migración
    Por ejemplo, si divides Fullname en FirstName y LastName, un diff simple solo expresa la mitad del cambio
    En EF Core, los métodos Up/Down manejan transformaciones reversibles
    Me pregunto cómo se manejan las transformaciones de datos sin un concepto así

• Nosotros hicimos internamente una herramienta de transformación basada en XML
  Como XML es más fácil de parsear que SQL, compara el esquema definido en XML con la DB y aplica solo los cambios necesarios
  Usábamos Sybase SQLAnywhere, y cuando había materialized views involucradas, agregar o eliminar columnas tenía la complejidad de recrear las vistas y los índices
  Por eso agregamos protecciones para que eliminar columnas solo se permitiera de forma explícita, y los cambios de tipo solo se hicieran cuando fueran seguros
  Hizo que las migraciones fueran muy simples en cientos de instalaciones on-premise
  Solo había que modificar el XML y la herramienta se encargaba del resto, además de que se le podían agregar funciones cuando hacía falta

• En SQLite, manejar la eliminación de columnas no funciona bien
  DROP COLUMN apenas se agregó en versiones recientes, pero en la mayoría de los dispositivos todavía no está soportado
  En el ejemplo, agrega x integer not null e intenta hacer DROP, pero solo aparece el mensaje “-- Skipped”
  La forma estándar es crear una tabla temporal, copiar los datos y luego reemplazarla, pero esta herramienta no lo automatiza
  Como es una parte donde es fácil equivocarse si hay restricciones de por medio, eso decepciona un poco
  Al final, si solo va a resolver las tareas fáciles, siento que es mejor hacerlo manualmente

• Esta herramienta parece útil solo en una base de datos vacía
  No puede manejar migraciones de datos, y por ejemplo no sirve con tablas que tienen datos reales en casos como convertir una columna JSONB a una forma estructurada, o cuando tras eliminar una columna genera ADD COLUMN … NOT NULL al hacer una migración inversa