Databricks detalla la ramificación de Lakebase para pruebas de CI/CD
Databricks detalló cómo la ramificación por copia en escritura de su base de datos Lakebase Postgres redujo el tiempo de aprovisionamiento de bases de datos para CI/CD del cliente Snorkel AI de más de 30 minutos a menos de 60 segundos.
Respuesta rápida
¿Qué anunció Databricks sobre la ramificación de bases de datos de Lakebase para CI/CD?
Databricks afirma que su base de datos serverless Postgres Lakebase utiliza ramificación copy-on-write para ofrecer a cada solicitud de extracción de CI/CD una copia aislada y editable de los datos de producción en menos de 60 segundos, en lugar de más de 30 minutos, según demuestra un caso de estudio con la clienta Snorkel AI, que gestiona unas 100 ramas simultáneas sobre un conjunto de datos de aproximadamente 2,5 terabytes.
Claves
- Databricks afirma que el sistema de ramificación con copia en escritura (copy-on-write) de Lakebase permitió a su cliente Snorkel AI reducir el tiempo de aprovisionamiento de bases de datos para las solicitudes de incorporación de cambios (pull requests) en CI/CD de más de 30 minutos a menos de 60 segundos.
- Según la entrada del blog, Snorkel AI ejecuta alrededor de 100 ramas de solicitudes de incorporación de cambios (pull requests) simultáneas sobre un conjunto de datos de producción de unos 2,5 terabytes, y cada rama añade apenas entre 5 y 10 gigabytes de almacenamiento adicional para sus propios cambios.
- Databricks afirma que las ramificaciones mantienen seguros los datos de producción mediante redes privadas, inicio de sesión único con Okta para los desarrolladores y tokens OAuth de corta duración para los pipelines de CI que se ejecutan como entidades de servicio.
- Las configuraciones de expiración de ramas eliminan automáticamente cada rama de solicitud de extracción (pull request) una vez que ya no es necesaria, lo que, según Databricks, mantiene los costos de almacenamiento cercanos al tamaño de producción más el de las ramas activas.
- Databricks afirma que el mismo enfoque de ramificación puede dar a cada tarea individual de un agente de IA su propia copia aislada y descartable de una base de datos.
El problema
Snorkel AI, una empresa que desarrolla herramientas de desarrollo de datos para equipos de IA, ejecuta un pipeline de CI/CD en Kubernetes donde cada pull request abierta recibe su propio espacio de nombres efímero para pruebas. Según Databricks, Snorkel quería probar su código con datos reales de su base de datos de producción, un clúster Amazon Aurora PostgreSQL, pero restaurar una copia completa de esa base de datos tardaba unos 20 minutos por entorno. Databricks señala que esto resultaba demasiado lento para un flujo de trabajo en el que los desarrolladores abren pull requests a lo largo del día, por lo que Snorkel nunca había podido asignar una copia de la base de datos a cada pull request.
El enfoque de ramificación de Lakebase
Databricks afirma que Lakebase, su base de datos Postgres sin servidor, permitió a Snorkel crear una rama nueva, aislada y con permisos de escritura de su base de datos a partir de cualquier punto temporal, de forma similar a una rama de Git. Databricks describe estas ramas como de copia en escritura (copy-on-write), lo que significa que una rama nueva no copia ningún dato al crearse. En cambio, comparte páginas de almacenamiento con su rama padre, y solo las páginas que una rama modifica se escriben como almacenamiento nuevo. Según la publicación del blog, Snorkel utilizó AWS Database Migration Service para replicar su base de datos de producción de Aurora en una rama "main" de Lakebase, manteniéndola a unos dos minutos de la producción mediante captura continua de datos modificados. Databricks explica que el pipeline de CI de Snorkel invoca la API de Lakebase para crear una nueva rama a partir de main cada vez que se abre una pull request, establece un tiempo de expiración para la rama y la elimina cuando la pull request se cierra. Si ese paso de limpieza no se ejecuta, Databricks indica que la rama expira automáticamente cuando se agota su configuración de tiempo de vida.
Controles de seguridad
Databricks afirma que los datos de producción se desplazan entre Aurora, Lakebase y el clúster de CI de Snorkel a través de redes privadas y no de internet público. Según la empresa, los desarrolladores de Snorkel se autentican mediante el inicio de sesión único de Okta federado con la cuenta de Databricks, mientras que los pipelines de CI se ejecutan como entidades de servicio (service principals) de Databricks que obtienen tokens OAuth de corta duración a través del SDK de Databricks. Databricks señala que los registros de auditoría de Postgres registran la identidad de la entidad de servicio detrás de cada consulta, de modo que cada consulta puede rastrearse hasta el pipeline que la ejecutó.
Resultados reportados por Databricks
Databricks afirma que el tiempo de aprovisionamiento de bases de datos de Snorkel se redujo de más de 30 minutos a menos de 60 segundos tras adoptar la ramificación de Lakebase, y que el sistema está diseñado para soportar unas 100 ramas simultáneas de pull requests sobre un conjunto de datos de producción de aproximadamente 2,5 terabytes. Según la publicación del blog, cada rama de pull request escribe entre 5 y 10 gigabytes de cambios sobre la base compartida, y Snorkel implementó el sistema para entre 60 y 70 desarrolladores de distintos equipos. Databricks cita a un desarrollador anónimo de Snorkel, quien afirma que los trabajos anteriores de copia de datos "tardaban horas y con frecuencia topaban con cuellos de botella de red y de otro tipo en las distintas plataformas de CI", y que el equipo necesitaba una solución que cumpliera sus requisitos de seguridad y cumplimiento normativo para los datos que salían de su nube privada virtual.
Uso más allá de CI/CD
Databricks afirma que el mismo patrón de ramificación se aplica a agentes de IA que escriben SQL, ejecutan migraciones o modifican datos, de modo que cada tarea de un agente recibe su propia rama de la base de datos principal, lo que le permite leer y escribir datos sin afectar la producción ni el trabajo de otros agentes. La empresa señala que los agentes pueden ejecutarse como entidades de servicio con tokens OAuth de corta duración, y que las ramas pueden revisarse y eliminarse si los cambios de un agente no son deseados, o depurarse automáticamente mediante configuraciones de expiración.
Fuente: blog de Databricks, "Lakebase branching for CI/CD: lessons from 100 PR databases", publicado el 31 de octubre de 2026.
Preguntas frecuentes
- ¿Qué es la ramificación (branching) de Lakebase?
- Databricks afirma que la función de ramificación de Lakebase permite a los usuarios crear una copia aislada y editable de una base de datos Postgres a partir de cualquier momento en el tiempo mediante almacenamiento de copia en escritura, de forma similar a la creación de una rama en Git.
- ¿Cómo usó Snorkel AI la creación de ramas de Lakebase?
- Según Databricks, Snorkel AI asigna a cada solicitud de extracción (pull request) abierta su propia rama de Lakebase de su base de datos de producción Aurora PostgreSQL para las pruebas de CI/CD, lo que sustituye a un proceso que antes tardaba más de 30 minutos por entorno.
- ¿Cómo afirma Databricks que la bifurcación de Lakebase reduce los costes?
- Databricks afirma que el almacenamiento copy-on-write implica que cada rama solo consume espacio adicional por los datos que modifica, y que la capacidad de cómputo de cada rama se reduce a cero cuando está inactiva.
- ¿Puede usarse la ramificación de Lakebase fuera de CI/CD?
- Databricks afirma que el mismo patrón de ramificación funciona para los agentes de IA, al asignar a cada tarea de un agente su propia rama de base de datos desechable para leer, escribir y probar cambios sin afectar a producción.