Ramificación de bases de datos en Postgres: flujos de trabajo estilo Git con Databricks Lakebase

La base de datos es el último cuello de botella en tu flujo de trabajo de desarrollo

La ramificación de bases de datos es el elemento que falta en los flujos de trabajo de desarrollo modernos. Cada parte de la pila ha evolucionado para admitir la iteración rápida. El código tiene Git. La infraestructura tiene Terraform. Las implementaciones tienen canalizaciones de CI/CD que se ejecutan en minutos. Pero las bases de datos relacionales todavía funcionan como hace diez años.

La mayoría de los equipos comparten una única base de datos de staging. A los pocos días de su configuración, esa base de datos deja de estar sincronizada con producción. Los esquemas divergen a medida que los desarrolladores aplican migraciones en diferentes órdenes. Los valores de secuencia ya no coinciden. Los datos de prueba se acumulan y contaminan los resultados. Alguien eventualmente reinicia todo, y el ciclo comienza de nuevo.

Configurar un nuevo entorno es peor. El enfoque estándar es ejecutar pg_dump contra producción, esperar a que termine (minutos a horas dependiendo del tamaño de la base de datos), cargarlo en una nueva instancia, configurar el acceso y esperar que el resultado refleje realmente lo que se está ejecutando en producción. Para una base de datos de 500 GB, esto significa una operación de copia de 500 GB, más la computación y el almacenamiento para mantenerla en funcionamiento.

El resultado es predecible. Los equipos evitan crear nuevos entornos porque son demasiado caros y lentos. Los desarrolladores comparten una única base de datos de staging mutable. Las migraciones se prueban contra datos obsoletos, o no se prueban en absoluto. Las implementaciones de vista previa se ejecutan contra fixtures vacíos en lugar de esquemas realistas. Las pruebas de CI comparten estado y producen resultados inestables.

La base de datos se convierte en la parte de la pila que los desarrolladores temen tocar.

Databricks Lakebase Postgres cambia esto con la ramificación de bases de datos.

Qué es realmente la ramificación de bases de datos

Una rama de base de datos no es una copia de base de datos. Esta distinción es importante porque cambia por completo la economía de los entornos aislados.

Cuando copias una base de datos, duplicas todos sus datos y esquema en una nueva instancia independiente. El tiempo y el costo escalan linealmente con el tamaño de la base de datos. Cada copia es un clon completo, y cada clon comienza a quedarse obsoleto en el momento en que se crea.

Una rama funciona de manera diferente. Cuando creas una rama en Lakebase, obtienes un nuevo entorno Postgres completamente aislado que:

• Comienza con el esquema y los datos exactos de su padre en un momento específico
• Comparte el mismo almacenamiento subyacente en lugar de duplicarlo
• Solo escribe nuevos datos cuando realizas cambios

Esto se llama copy-on-write (copiar al escribir). Mientras dos ramas no hayan divergido, hacen referencia a los mismos datos almacenados. Cuando ejecutas una migración, insertas filas o modificas tablas en una rama, solo esos cambios se escriben por separado. Todo lo demás se comparte con el padre.

Copia de base de datos vs. rama de base de datos

En términos prácticos, esto significa:

• La creación de ramas toma segundos, independientemente del tamaño de la base de datos. Una base de datos de 10 GB y una de 2 TB se ramifican en la misma cantidad de tiempo.
• El costo de almacenamiento es proporcional a los cambios, no al tamaño total de los datos. Una rama que modifica 50 MB de datos en una base de datos de 500 GB utiliza aproximadamente 50 MB de almacenamiento adicional.
• Cada rama obtiene su propia cadena de conexión Postgres y punto final de cómputo. Las ramas están completamente aisladas entre sí y de su padre.
• Las ramas inactivas escalan automáticamente el cómputo a cero. Solo pagas por el cómputo activo cuando se está utilizando una rama.

Las ramas están diseñadas para ser creadas, utilizadas y descartadas libremente. Por desarrolladores, por canalizaciones de CI, por agentes de IA, por automatización. No son entornos preciosos que necesiten ser mantenidos. Son desechables, como las ramas de Git.

La arquitectura que hace posible la ramificación de bases de datos

Postgres administrado tradicional (RDS, Azure Database for PostgreSQL) une el cómputo y el almacenamiento. El proceso de la base de datos y sus datos viven en la misma instancia, y los datos se almacenan como un único sistema de archivos mutable. Es por eso que la copia es la única opción para crear un segundo entorno: tienes que duplicar el sistema de archivos.

Pero un lakebase está construido de manera diferente. Separa completamente el cómputo del almacenamiento. Todos los datos se escriben en un motor de almacenamiento distribuido y versionado que registra cada cambio como una nueva versión en lugar de sobrescribir los datos existentes. Esta arquitectura de registro estructurado es lo que hace posible la ramificación de bases de datos como un elemento primitivo en lugar de una característica superpuesta.

Debido a que el almacenamiento está versionado, múltiples ramas pueden hacer referencia a los mismos datos subyacentes sin riesgo de conflicto. Debido a que el cómputo es independiente, cada rama ejecuta su propio proceso Postgres y escala por sí misma. Las ramas no productivas que permanecen inactivas escalan a cero automáticamente y se reinician en milisegundos cuando llega una conexión.

No todas las implementaciones de ramificación de bases de datos son iguales. Algunas plataformas crean copias completas de instancias y las llaman ramas. Otras ramifican solo el esquema, sin datos. Las ramas de Lakebase incluyen tanto el esquema como los datos, utilizan copy-on-write en la capa de almacenamiento para evitar la duplicación y proporcionan cómputo independiente y escalable automáticamente por rama. Esto es lo que hace práctico crear ramas libremente y a escala, sin aprovisionar infraestructura adicional.

Esta arquitectura también permite el viaje en el tiempo. Debido a que cada versión de los datos se conserva dentro de una ventana de restauración configurable, puedes crear una rama desde cualquier punto del pasado, no solo desde el estado actual. Esto es lo que potencia la recuperación instantánea punto a punto: en lugar de reproducir registros WAL o restaurar una copia de seguridad, creas una rama en la marca de tiempo que necesitas y lees directamente de ella.

Lo que la ramificación de bases de datos desbloquea para tu equipo

Una vez que la ramificación de bases de datos es un elemento primitivo rápido y barato en lugar de una operación de copia costosa, nuevos flujos de trabajo se vuelven prácticos. Aquí hay un resumen de los patrones más comunes. (Cubrimos cada uno de estos en detalle en la próxima publicación de esta serie).

Una rama por desarrollador. Cada ingeniero obtiene su propio entorno aislado con datos similares a los de producción. No más pisarse los cambios en una base de datos de desarrollo compartida. Cuando una rama se desvía demasiado de producción, restáurala con un solo comando para obtener el último esquema y datos. Debido a que las ramas escalan a cero cuando están inactivas, este patrón sigue siendo asequible incluso en equipos grandes.

Una rama por pull request. Automatiza la creación de ramas cuando se abre un PR y la eliminación cuando se fusiona o se cierra. Las implementaciones de vista previa en Vercel o Netlify obtienen su propia rama de base de datos, por lo que tu vista previa de frontend está respaldada por datos realistas y aislados. Las migraciones se ejecutan contra formas y restricciones de datos reales, no contra fixtures vacíos. Este es el flujo de trabajo que los equipos adoptan primero, y tiende a ser el que los convence de adoptar la ramificación de bases de datos en general.

Una rama por ejecución de prueba. Las canalizaciones de CI obtienen una base de datos fresca y aislada para cada ejecución. No hay estado residual de pruebas anteriores. No hay que esperar a que una imagen de contenedor vacía se inicie y luego se llene con datos falsos. No hay resultados inestables causados por datos compartidos o dependencias en el orden de las pruebas. Cada ejecución comienza desde la misma línea base. Para las pruebas que requieren datos deterministas, puedes crear ramas desde un punto fijo en el tiempo o un Número de Secuencia de Registro (LSN) específico.

Recuperación instantánea. Cree una rama desde cualquier punto en el tiempo dentro de su ventana de restauración. Inspeccione tablas eliminadas, depure migraciones fallidas o audite datos históricos, todo sin tocar producción. Utilice la diferencia de esquemas para comparar el estado antes y después de un cambio. Exporte lo que necesite de la rama de recuperación y luego elimínela. Todo el proceso toma segundos, no las horas o días que requiere la recuperación ante fallos tradicional (PITR).

Entornos efímeros para agentes de IA. Los agentes de IA pueden aprovisionar bases de datos mediante programación a través de la API de Lakebase, usarlas durante la duración de una tarea y apagarlas cuando terminen. Las plataformas pueden crear versionado sobre instantáneas: cada acción del agente crea un punto de control y los usuarios pueden saltar entre versiones instantáneamente. Si un agente ejecuta una migración incorrecta o corrompe datos, revertir es una sola llamada a la API.

Comenzando

La ramificación de bases de datos en Databricks Lakebase convierte su base de datos Postgres de la parte más lenta de su flujo de trabajo de desarrollo en la más rápida.

Puede crear su primera rama en menos de un minuto usando la consola, CLI o API. Así es como se ve desde la CLI:

Eso es todo. Ahora tiene un entorno Postgres aislado con el esquema y los datos completos de producción, listo para usar.

Si está construyendo sobre Postgres y está cansado de la sobrecarga que conlleva la gestión de entornos de bases de datos, comience con una sola rama de desarrollo. Luego pruebe una por PR. La mayoría de los equipos que comienzan con un flujo de trabajo de ramificación de bases de datos rápidamente adoptan el resto.

Databricks Lakebase es Postgres sin servidor construido para agentes y aplicaciones. Obtenga más información en databricks.com/product/lakebase.

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