Databricks detalla el branching de Lakebase para agentes de codificación paralelos

Databricks, el 8 de octubre de 2026, publicó una publicación del blog que detalla un flujo de trabajo de desarrollo en el que cada agente de codificación paralelo y cada pull request se ejecutan contra su propia base de datos Postgres aislada y efímera, creada mediante el branching copy‑on‑write incorporado en su servicio de base de datos Lakebase.

En la publicación, Databricks describe la base de datos como una parte a menudo pasada por alto del flujo de trabajo de desarrollo en un momento en que los agentes de codificación están asumiendo una cuota creciente del trabajo de desarrollo y ejecutar varios agentes en paralelo se está convirtiendo en la norma. Con entornos compartidos tradicionales, como una única base de datos de desarrollo o de staging, los agentes concurrentes pueden entrar en conflicto por cambios de esquema, interferir entre sí o recurrir a simulaciones que no reflejan datos del mundo real. Estos ya eran puntos de dolor para los desarrolladores, indica la publicación, pero los agentes los agravan porque se mueven más rápido, operan en paralelo y necesitan un entorno seguro que evite poner en riesgo los datos de producción o exponer datos sensibles.

Mecánicas de branching

Databricks afirma que el branching de Lakebase permite a un usuario ramificar una base de datos completa en menos de un segundo, sin importar su tamaño. Las ramas se basan en almacenamiento copy‑on‑write: una nueva rama hereda el esquema y los datos de su padre mientras comparte el almacenamiento subyacente, consumiendo almacenamiento adicional solo a medida que diverge. Según la documentación de branching de Lakebase de Databricks, cada proyecto se crea con una rama predeterminada llamada production, y toda rama, excepto la rama raíz, tiene un padre. Los cambios en una rama hija nunca afectan a su padre, y el aislamiento se extiende al estado de roles de Postgres: los roles y bases de datos creados, los GRANT y REVOKE aplicados, y los atributos de rol modificados en una rama no tienen efecto en otras ramas.

Cada rama tiene su propio cómputo, se escala a cero cuando está inactiva y solo se factura por las horas de cómputo activas, según la documentación. La facturación del almacenamiento depende de si una rama expira: una rama que expira se factura solo por los datos modificados en ella, mientras que una rama permanente sin expiración se factura por su tamaño total de datos, como una base de datos independiente. Un restablecimiento de rama, que actualiza una rama hija a partir de su padre, funciona en una sola dirección, de padre a hijo. La recuperación puntual crea una nueva rama raíz a partir de datos históricos dentro de la ventana de restauración, dejando la rama original sin cambios y operativa.

En su página de producto, Databricks describe Lakebase como un servicio Postgres completamente gestionado y sin servidor que ejecuta el motor Postgres de código abierto en lugar de una bifurcación.

Una rama por agente

El flujo de trabajo descrito en la publicación combina los worktrees de Git con las ramas de Lakebase. Un worktree otorga a cada agente su propio directorio con su propia rama revisada, eliminando conflictos a nivel de archivo entre agentes, y un hook post‑checkout crea automáticamente una rama de base de datos para cada nuevo worktree. En el ejemplo, construido con Claude Code, un agente ejecuta claude -worktree feature-123, Git crea el worktree, se dispara el hook, y el agente termina con su propio directorio de código y su propia base de datos totalmente aislada. Los archivos de instrucción del repositorio, como AGENTS.md o CLAUDE.md, guían el comportamiento del agente, y cuando el agente finaliza abre un pull request, tras lo cual tanto el worktree como la rama de base de datos pueden ser retirados.

Una diferencia respecto a Git, señala la publicación, es que las ramas de Lakebase no se fusionan de nuevo en la rama principal, porque padre e hijo pueden cambiar independientemente y reconciliar sus datos puede volverse rápidamente impracticable. En su lugar, los cambios de esquema se rastrean en el código junto con la lógica de la aplicación y se promueven a la rama padre mediante migraciones, usando herramientas como Drizzle, Flyway, Liquibase o Alembic. El ejemplo utiliza Drizzle: cuando se necesita un cambio de esquema, el agente agrega la migración correspondiente al código, y la automatización de despliegue la aplica al desplegar la aplicación de vista previa y nuevamente cuando el cambio se fusiona en main.

Una rama por pull request

Para la integración continua, la publicación describe un flujo de trabajo de GitHub Actions en el que abrir un pull request contra main activa el CLI de Lakebase para crear una rama efímera, nombrada según el pull request, como hija de la rama production, y esa rama se convierte en el entorno de base de datos del pull request. La herramienta de migración se ejecuta contra la nueva rama, se despliega una aplicación de vista previa apuntando a la cadena de conexión de la rama, y se genera un diff de esquema que se publica como comentario del pull request mostrando exactamente qué tablas, columnas o índices cambiaron. Cuando el pull request se cierra o se fusiona, la automatización elimina la rama. Dado que la rama parte de production, la migración de esquema puede aplicarse y probarse antes de que el cambio llegue a producción. El ejemplo despliega vistas previas en Databricks Apps, aunque la publicación indica que el concepto se aplica a otras plataformas de alojamiento como Vercel, Netlify y Cloudflare.

En cuanto a entornos, la publicación señala que una configuración típica de Lakebase utiliza un espacio de trabajo de Databricks por entorno, como desarrollo, staging y producción, y que los equipos suelen ramificar a partir de una base de datos sembrada en lugar de la base de datos de producción para evitar exponer datos sensibles como PII. La guía utiliza un solo espacio de trabajo por simplicidad, aunque indica que los mismos conceptos se aplican a configuraciones de múltiples espacios de trabajo.

Reproducción de errores y pruebas de migración

Más allá de los bucles por agente y por pull request, la publicación describe flujos de trabajo de ramificación que no están implementados en el repositorio de ejemplo. Un desarrollador puede crear una rama aislada a partir de producción en un momento específico, típicamente justo antes de que apareciera un error, reproducir e investigar el problema con datos reales, y retirar la rama una vez que se valida la corrección. Los equipos también pueden crear una rama antes de desplegar a producción, aplicar una migración de esquema, ejecutar pruebas y verificar que la aplicación sigue comportándose como se espera antes de promover el cambio. Estos flujos de trabajo permiten a los desarrolladores trabajar con datos similares a los de producción o derivados de producción, usando, por ejemplo, el enmascaramiento de Unity Catalog, sin poner en riesgo la base de datos en vivo, según indica la publicación.

La publicación enlaza a un repositorio de ejemplo en GitHub, en el directorio Lakebase-Agentic-CI del repositorio databricks/tmm, que contiene ejemplos de flujos de trabajo de GitHub Actions que implementan el patrón. Concluye que, en conjunto, estos patrones forman lo que llama el bucle de desarrollo Lakebase: una rama por agente, una rama por pull request y ramas aisladas para la validación en producción.