Habilitar el desarrollo evolutivo de bases de datos: ramificación de bases de datos con Lakebase

Por qué existe esta serie

La metodología descrita en Evolutionary Database Design y operacionalizada en Refactoring Databases: Evolutionary Database Design ha sido clara durante veinte años. Las siete prácticas, el catálogo de más de 70 refactorizaciones con nombre, la mecánica de transición – todo documentado, revisado por pares, enseñado.

Esa metodología llegó a CI/CD en 2010 con Continuous Delivery (Capítulo 12: Gestión de Datos). Las migraciones se convirtieron en artefactos de primera clase en el pipeline de despliegue. La disciplina de los cambios de base de datos como código llegó al movimiento CI/CD más amplio. Lo que CD no resolvió fue el aislamiento por pipeline: los pipelines podían ejecutar migraciones, pero aún necesitaban una base de datos de destino, y ese destino se compartía. La práctica n.º 4 – Cada uno obtiene su propia instancia de base de datos – se ha mantenido aspiracional en la mayoría de los equipos porque las bases de datos reales por desarrollador y con forma de producción cuestan tiempo, dinero y ciclos de DBA. La capa compensatoria que surgió para solucionar la brecha (objetos simulados, entornos de staging compartidos, sustitutos de bases de datos en memoria, colas de tickets de DBA) se convirtió en metodología fundamental por defecto, no por diseño.

En 2026, la ramificación de bases de datos de copia en escritura llega a Databricks Lakebase. Una rama de un segundo, sin almacenamiento en la creación, de una base de datos de producción a escala de terabytes es ahora una operación O(1). La restricción que mantenía la práctica n.º 4 como aspiracional se ha levantado.

Esta serie describe qué cambia cuando se levanta la restricción: no la metodología – esa se mantiene – sino las prácticas que emergen por primera vez, la gobernanza a escala de equipo que se vuelve automática, la evolución del rol del DBA y el nuevo sustrato que los agentes comparten con sus homólogos humanos.

Conoce a Jen

Jen es el personaje desarrollador del ensayo Evolutionary Database Design. En ese ensayo implementó una refactorización de base de datos – dividir un campoinventory_code enlocation_code,batch_number yserial_number – como una historia de usuario rutinaria, ilustrando que los DBA y los desarrolladores pueden colaborar, los esquemas pueden evolucionar en pequeños incrementos y las migraciones transportan el cambio de forma segura.

La serie retoma a Jen veinte años después. La metodología que sigue es la misma que seguía en 2003. Lo nuevo es el sustrato debajo de su flujo de trabajo: la ramificación de bases de datos de copia en escritura, que hace que las prácticas sobre las que ha estado leyendo sean operativamente reales a escala de producción. A lo largo de las tres partes de esta serie, es la misma Jen en tres ámbitos: su día (Parte 1), su nuevo playbook (Parte 2) y su equipo (Parte 3).

Parte 1: La historia de Jen: una característica, un cambio de base de datos

Para entender cómo funciona esto, repasemos el viaje de cómo una desarrolladora llamada Jen implementa una tarea que indica que el usuario debe poder ver, buscar y actualizar la ubicación, el lote y el número de serie de una producción en inventario.

Lo siguiente describe los diversos pasos que Jen tiene que dar para lograr esta tarea, y al describir los pasos, intentaremos comparar cómo cambia el flujo de trabajo de Jen al trabajar con bases de datos tradicionales y al usar Lakebase, que permite la ramificación de bases de datos a un costo mínimo.

Jen comienza a trabajar en su tarea de característica

Jen retoma lo que parece una característica sencilla. El equipo de producto quiere permitir a los usuarios capturar la ubicación, el lote y el número de serie de un artículo durante la adición de inventario y usarlo más tarde en el flujo de la aplicación. Desde fuera, el cambio parece pequeño: añadir un campo a la pantalla, guardar el valor, mostrarlo en la pantalla de Inventario de un artículo y tal vez usarlo en una decisión posterior.

Para Jen, el cambio de aplicación es fácil de imaginar. Sabe dónde está el formulario. Sabe qué servicio maneja la solicitud. Puede ver el objeto modelo que necesita más atributos. Pero en el momento en que rastrea el cambio por completo, ve la dependencia real, la base de datos también tiene que cambiar.

Se necesitan algunas columnas nuevas, los datos existentes en el entorno de producción deben conservarse y deben ser semánticamente correctos. La aplicación debe manejar datos antiguos y nuevos de forma segura y ella necesita añadir pruebas para demostrar que los nuevos campos se almacenan, leen y muestran correctamente. Lo que parecía una característica simple es ahora un cambio coordinado de aplicación y base de datos, con la responsabilidad añadida de garantizar que el esquema y los datos de producción existentes se migren al nuevo esquema.

Base de datos compartida

Jen crea una rama de código para el trabajo que está a punto de emprender, y dado que están usando una base de datos compartida y el resto del equipo está usando la misma base de datos para el desarrollo, inmediatamente comienza a pensar en todos los cambios que va a introducir en la capa de base de datos que podrían afectar a otros usuarios de la base de datos compartida y comienza a planificar cómo puede hacerlo seguro para los demás. ¿Podría ejecutar el cambio de aplicación localmente y poder ejecutar sus pruebas unitarias y de integración? Cada opción tiene costos. Puede esperar. Puede pedir al equipo que se coordine. Puede configurar su propio Postgres local en Docker, sembrarlo con unpg_dump obsoleto de hace una semana y esperar que las diferencias no importen. Puede recurrir a ejecutar una base de datos local en un contenedor o a una base de datos en memoria H2 o SQLite que se ejecuta rápido pero usa el dialecto incorrecto, por lo que sus pruebas pasan localmente y muestran fallos desconocidos en Postgres real. ¿Puede incluso probar sus scripts de migración de esquemas y datos? Este miedo a romper el trabajo de otros la frena y al mismo tiempo no le permite experimentar con múltiples opciones para construir la característica.

Dado que en una base de datos compartida, un desarrollador puede estar probando un cambio de lógica de negocio, otro está depurando una migración de datos, alguien más creó datos de prueba que Jen no entiende. Si Jen aplica su cambio de esquema a la base de datos compartida, puede romper el trabajo de otra persona. Si alguien más cambia el esquema mientras ella está probando, sus resultados pueden ya no ser confiables. Si añade datos de prueba, puede interferir con las suposiciones de otro desarrollador.

Jen puede esperar hasta que la base de datos compartida esté libre, lo que protege al equipo de colisiones, pero convierte una característica pequeña en un problema de programación y una pérdida de productividad. Puede coordinarse manualmente con los otros desarrolladores: “¿Estás usando dev ahora mismo?” “¿Puedo ejecutar una migración?” “Por favor, no reinicies los datos durante la próxima hora.” algo así como un testigo en una carrera de relevos. Eso funciona durante un tiempo, pero no escala, especialmente con un equipo remoto o en diferentes zonas horarias.

Jen piensa en otra opción, usar una base de datos local en memoria. Sabe que esta configuración no coincide con el estado de la base de datos utilizada por el resto del equipo, lo que significa que no tendrá confianza en su solución, ya que el cambio puede funcionar localmente y aún fallar más tarde cuando se encuentre con los datos y el esquema reales en entornos superiores como staging y producción.

El verdadero problema que Jen está encontrando es de retroalimentación más lenta . Puede hacer el cambio, pero averiguar si el cambio funciona. Pero sin una retroalimentación rápida y realista, el cambio de base de datos se convierte en algo que el equipo trata con cuidado y termina eligiendo la primera solución que funciona y nunca experimenta ni prueba múltiples soluciones, lo que lleva a soluciones subóptimas, reducción de la productividad y desarrolladores insatisfechos.

Ramas de bases de datos individuales

Usando Lakebase, Jen tiene la capacidad de ramificar una base de datos para su uso individual y esta capacidad cambia completamente la forma en que trabaja.

En lugar de esperar a que la base de datos de desarrollo compartida esté disponible, Jen crea una rama de base de datos databricks postgres create-branch para su característica o usando una Extensión de VS Code / Cursor. Esto cambia la forma del trabajo de inmediato. Ya no le pide al equipo una ventana de tiempo. Ya no negocia con otros desarrolladores sobre quién puede ejecutar qué migración y cuándo. Ya no intenta proteger su cambio a medio terminar de los cambios a medio terminar de los demás. Tiene su propio espacio de base de datos aislado, creado a partir del mismo tipo de entorno de base de datos que la aplicación utilizará finalmente en producción.

La rama le da a Jen una copia rápida del estado de la base de datos con la que necesita trabajar. Ahora tiene el mismo motor Postgres, el mismo esquema, las mismas políticas de gobernanza y los mismos datos con forma de producción que vería si consultara producción directamente. La única diferencia: esta rama se puede modificar, descartar o recrear sin afectar ninguna otra carga de trabajo. No está probando contra una base de datos local simplificada que se comporta de manera diferente a la producción. Está trabajando con el mismo tipo de base de datos que el equipo usa en producción, con los mismos tipos de reglas de esquema, restricciones, índices, datos de referencia y historial de migración que hacen que los cambios en la base de datos tengan éxito o fallen en el mundo real. Ese realismo importa porque muchos problemas de bases de datos no aparecen en pruebas unitarias aisladas. Aparecen cuando una nueva migración se encuentra con la estructura existente, los datos existentes, las suposiciones existentes y el comportamiento de la aplicación existente.

Ahora Jen puede tratar el cambio de base de datos como parte del diseño, no solo como un paso de implementación. Puede probar la versión obvia primero: agregar las nuevas columnas, establecer una lógica predeterminada para dividir la columna existente, crear un script de migración de base de datos, actualizar la aplicación y ejecutar las pruebas. Luego puede hacer mejores preguntas. ¿Debería este script de migración funcionar para los volúmenes de datos de producción, la calidad de los datos en producción es como espera su script? ¿Es un script de migración de datos que oculta información comercial faltante? ¿Debería la preferencia modelarse como columnas simples, una tabla de búsqueda o una tabla de información de elementos separada porque es probable que venga más información más adelante? ¿El patrón de consulta necesitará un índice? ¿Este diseño facilitará o dificultará la generación de informes posteriores? En el flujo de trabajo anterior, estas preguntas a menudo se comprimen porque cambiar la base de datos es costoso.

En el flujo de trabajo ramificado, Jen puede explorarlas mientras la característica aún se está dando forma. El DBA puede emparejarse con ella para guiarla sobre los matices de producción y los volúmenes de datos, brindando así información valiosa en el diseño de la solución en lugar de ser un revisor posterior al hecho.

Realizando el cambio de aplicación y base de datos juntos

Jen escribe el script de migración. Lo que sea que use su equipo: Flyway, Liquibase, Alembic, Knex, Prisma, el script vive en el repositorio de código, junto con los cambios de la aplicación. El esquema y la migración de datos viajan con el código.

(Esta es la refactorización de Split Column – uno de ~70 patrones catalogados en Refactoring Databases, el libro que operacionalizó las siete prácticas.)

Aplica la migración a su rama usando flyway migrate. La herramienta se ejecuta en menos de un segundo contra datos con forma real. Actualiza el código de su repositorio para leer y escribir las tres nuevas columnas. Ejecuta su conjunto de pruebas. Las pruebas pasan contra Postgres real, sin mocks, sin sustitutos en memoria.

Si quiere una pizarra limpia para probar un enfoque diferente, descarta la rama y crea una nueva a partir de producción. Otro segundo. Sin tickets de limpieza. Sin DBA involucrado.

La misma Jen. La misma refactorización. Lo que cambió fue la capacidad.

Espacio para fallar más rápido

La capacidad de experimentar es importante. El diseño y desarrollo evolutivo no se trata solo de moverse rápidamente a través de una lista de verificación predefinida. También se trata de aprender a medida que el trabajo se vuelve más concreto. Jen puede descubrir que el primer diseño de esquema funciona pero crea una lógica de aplicación incómoda. Puede descubrir que el segundo diseño es más limpio pero complica la migración de registros existentes. Puede descubrir que una pequeña decisión de normalización ahora facilitaría los cambios futuros. El primer script de migración que escribió, los índices SUBSTRING están desfasados. El DROP COLUMN destructivo se ejecutó antes de que pudiera verificar que las nuevas columnas se habían poblado correctamente. Debido a que tiene su propia rama, estos descubrimientos son económicos. Puede aplicar una migración, ejecutar la aplicación, inspeccionar los datos, avanzar con otra migración o restablecer e intentar un camino diferente.

La rama también cambia la postura emocional del trabajo. Jen no tiene que ser excesivamente cautelosa porque alguien más podría depender de la base de datos de desarrollo compartida. No tiene que anunciar cada experimento al equipo. No tiene que limpiar los datos de prueba de inmediato porque otro desarrollador podría tropezar con ellos. Su rama es un lugar seguro para el pensamiento inacabado. Puede contener tablas temporales, intentos de migración fallidos, datos de prueba incómodos y diseños a medio formar sin crear ruido para nadie más.

Al mismo tiempo, el aislamiento no significa desapego de los estándares del equipo. Jen todavía escribe scripts de migración. Todavía mantiene el código de la aplicación y el cambio de base de datos juntos. Todavía ejecuta pruebas. Todavía espera que el diseño final sea revisado. La diferencia es que puede hacer la parte sucia del trabajo en privado y rápidamente antes de pedirle al equipo que razone sobre la versión pulida. Para cuando abra una solicitud de extracción, la conversación puede centrarse en si el diseño es correcto, no en si tenía un lugar seguro para probarlo.

Este es el cambio clave: la rama de la base de datos le da a Jen comentarios rápidos, realistas y aislados que también puede revisar con sus líderes técnicos o DBAs, mostrándoles su rama de base de datos. Rápido significa que puede crear el entorno cuando lo necesita, no cuando alguien se lo proporciona. Realista significa que está probando contra el mismo tipo de comportamiento de base de datos que importa en producción. Aislado significa que sus experimentos no interrumpen a nadie más. Juntas, esas tres propiedades convierten el cambio de base de datos de un cuello de botella a una parte normal del desarrollo de características.

Jen ahora puede avanzar la aplicación y la base de datos juntas. Su rama de código y su rama de base de datos se convierten en dos lados de la misma tarea. Una contiene los cambios de la aplicación. La otra le da a esos cambios una base de datos real contra la que vivir. En lugar de esperar, coordinar o fingir con una configuración simplificada, Jen puede diseñar, probar, revisar y aprender. La característica sigue siendo pequeña, pero ahora la base de datos ya no es lo que la hace lenta.

Abriendo la solicitud de extracción

Jen confirma tanto el código de la aplicación como el script de migración. Abre una PR.

CI hace lo que Jen acaba de hacer, pero para el equipo: crea su propia rama temporal de Lakebase, aplica la migración, ejecuta el conjunto de pruebas de la aplicación, ejecuta pruebas de base de datos contra el esquema migrado, valida la migración en sí (se aplica limpiamente, es idempotente, reversible) y publica un comentario en la PR mostrando exactamente qué objetos de base de datos cambiaron.

El revisor ahora puede ver lo que hace el cambio de esquema en línea con el código que lo utiliza, cambiando su comprensión contextual de abstracto a concreto.

Captura de pantalla de la vista de resumen de diferencias de rama de la Extensión Lakebase SCM

Revisando el cambio

En el flujo de trabajo anterior, la pregunta de revisión de la base de datos era "¿esto romperá la base de datos?", controlada por un DBA que tenía que examinar cada cambio de forma aislada porque cada cambio tenía consecuencias a escala de producción si se liberaba. Las revisiones eran síncronas. Los horarios chocaban. El calendario del DBA se convirtió en una cola y, a veces, se omitía al DBA por razones de "Tiempo de comercialización".

En el nuevo flujo de trabajo, la pregunta es "¿es este el diseño correcto?". El DBA ya ha visto la diferencia de esquema publicada por CI. Ya ha visto la migración ejecutarse correctamente contra una rama de datos real. Jen también puede involucrar al DBA para una discusión, para mostrar lo que está pensando y todas las demás opciones que ha probado. El DBA puede revisar según su horario, no el de Jen. Pueden proporcionar una revisión mucho antes en el ciclo de desarrollo de la solución y mejorar la solución en torno a la integridad de los datos, la estrategia de indexación, la extensibilidad futura o la mantenibilidad a largo plazo, no en el control de protección que solía ocupar todo su tiempo.

El equipo revisa el código y la base de datos juntos. Una PR. Una conversación. Misma ventana.

Fusionando con confianza

La migración ya se ha probado contra una rama de datos real. La aplicación ya se ha ejecutado contra el esquema modificado. La migración del esquema ha sido revisada. La compilación de CI ha ejecutado exactamente los mismos pasos y ha estado en verde durante una hora.

Cuando Jen fusiona, la migración se aplica al siguiente entorno, las ramas de base de datos y código para el entorno de CI y Jen se limpian. Asegurando así que el cambio de base de datos ya no sea una sorpresa de última hora del lanzamiento.

Lo que Jen acaba de hacer es la quinta práctica del ensayo de 2003: integración continua de cambios en la base de datos.

Lo que muestra el viaje de Jen

El cambio de base de datos se convierte en parte del desarrollo normal. La ramificación reduce la espera, el riesgo y la sobrecarga de coordinación. El bucle diario de Jen ahora le da una retroalimentación rápida y aislada en la capa de la base de datos.

En la Parte 2 – El Nuevo Manual de Jen, explicamos qué se elevó y por qué la capa compensatoria con la que Jen trabajó durante toda su carrera puede desaparecer: ramificación de copia en escritura, la arquitectura que la hace funcionar y las optimizaciones de metodología que siguen.

En la Parte 3 – El Equipo de Jen a Escala, analizamos cómo se ve la historia de Jen cuando es una de cincuenta desarrolladores, o tal vez está trabajando en un producto de marca blanca, o está trabajando en un monolito modular con muchos dominios dentro: gobernanza en la creación de ramas, el cambio de enfoque del DBA, el agente en el bucle y el trabajo de diseño de la plataforma que se abre cuando el calendario del DBA no es una cola de tickets.

Para los lectores que desean un recorrido por las herramientas IDE que Jen usó en esta publicación, está el Complemento: Recorrido de Plugins – la Extensión SCM de Lakebase para VS Code / Cursor, de principio a fin.

Finalmente, pronto se lanzará un Kit de Desarrollo de Aplicaciones Lakebase para que los agentes lo usen, acompañado de un ebook para que los humanos lo sigan.

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original