Databricks se ha consolidado como la plataforma de referencia para analítica avanzada, machine learning y gobierno de datos en grandes organizaciones. Pero durante años ha tenido un límite claro: no estaba pensada para que las aplicaciones de negocio operaran directamente sobre ella. Si un ERP necesitaba actualizar stock en tiempo real, o una aplicación interna requería persistencia transaccional, la respuesta siempre pasaba por añadir una base de datos OLTP externa y construir los procesos de sincronización correspondientes.
Lakebase es la respuesta de Databricks a ese problema. En este artículo te explicamos qué es exactamente, qué arquitectura introduce, qué puedes hacer con ella hoy y cómo evaluar si tiene sentido en tu organización.
El problema que viene de antes
El Lakehouse en Databricks resolvió un problema histórico: unificar en una sola plataforma los datos para analítica, machine learning y reporting. Pero cuando las organizaciones necesitaron que sus aplicaciones operativas accedieran a esos mismos datos en tiempo real, la arquitectura mostraba sus límites.
El resultado habitual era una arquitectura duplicada: el Lakehouse para analizar, una base de datos OLTP externa para operar, y procesos ETL en medio para mantener ambos sincronizados. Esa arquitectura tiene un coste que va más allá del gasto en infraestructura. Los datos operativos y los analíticos nunca están del todo sincronizados, la gobernanza se complica porque los mismos datos viven en dos sistemas con permisos distintos, y el mantenimiento de esas sincronizaciones consume recursos que deberían ir a proyectos de valor.
Qué es Lakebase
Lakebase es un motor de base de datos PostgreSQL totalmente gestionado, integrado de forma nativa en Databricks, diseñado para cargas de trabajo OLTP en tiempo real sobre el Lakehouse.
Lo que lo diferencia de ejecutar un PostgreSQL convencional en la nube es arquitectónico: Lakebase separa completamente el cómputo del almacenamiento. Los datos se guardan en almacenamiento abierto en la nube, en formato compatible con Delta Lake, bajo el paraguas de Unity Catalog. El motor PostgreSQL funciona como una capa de cómputo elástica y serverless que opera sobre ese almacenamiento. Esa separación es el cambio central que explica la mayoría de sus ventajas.
Por qué esto importa más allá de lo técnico
Las bases de datos relacionales clásicas vinculan el cómputo y el almacenamiento en la misma infraestructura. Eso genera tres problemas a medida que las organizaciones escalan:
- El coste de mantener capacidad fija independientemente del uso.
- La dificultad de correr consultas analíticas pesadas sin afectar las operaciones en curso.
- La dependencia del proveedor cuando el almacenamiento está acoplado a infraestructura propietaria.
Lakebase está diseñado para eliminar estas tres restricciones desde la base.
Integración con el ecosistema Databricks
La integración de Lakebase dentro de Databricks no es superficial. Las tablas de Lakebase pueden sincronizarse con tablas Delta Lake, lo que permite que los datos transaccionales fluyan automáticamente hacia los pipelines analíticos sin construir procesos de sincronización manuales. Unity Catalog gestiona los permisos de la misma forma que el resto de activos de datos en el Lakehouse, simplificando la gobernanza y las auditorías de cumplimiento. Y Databricks Apps puede usar Lakebase como capa de persistencia para construir aplicaciones internas sin añadir infraestructura externa.
Para entender cómo Delta Lake actúa como base del almacenamiento en esta arquitectura, puedes consultar nuestro artículo sobre Delta Lake: qué es y cuándo implementarlo.
Las dos versiones actuales: Autoscaling y Provisioned
Hoy existen dos versiones de Lakebase disponibles en Databricks, con perfiles de uso distintos.
Lakebase Autoscaling
Es la versión más reciente y hacia donde se dirige el desarrollo futuro del producto. El cómputo se ajusta automáticamente a la demanda y escala a cero cuando no hay actividad, lo que elimina el coste de mantener instancias activas en periodos sin carga. Incorpora tres capacidades que marcan la diferencia en proyectos reales:
El branching permite crear copias instantáneas de la base de datos de producción para desarrollo o pruebas, sin duplicar el almacenamiento y sin riesgo para los datos activos. Un equipo puede probar una migración de esquema sobre una rama, validarla en aislamiento y aplicarla en producción solo cuando haya confirmación. El scale-to-zero elimina el gasto en capacidad ociosa: el cómputo se suspende automáticamente y se reactiva en segundos cuando llega una nueva petición. Y la restauración a punto en el tiempo permite recuperar la base de datos a cualquier momento dentro de una ventana de hasta 30 días, validable en una rama antes de aplicar cambios en producción.
Es la opción adecuada para cargas variables, entornos de desarrollo activo y aplicaciones con patrones de uso irregulares, como las que dirigen agentes de IA.
Lakebase Provisioned
La versión original, con cómputo aprovisionado que se dimensiona manualmente. Más predecible para cargas estables con picos bien definidos, donde la capacidad reservada ofrece un comportamiento más controlable. Ambas versiones son aptas para producción; la elección depende del perfil de uso y de si el branching o el scale-to-zero aportan valor concreto en tu caso.
La arquitectura general de Databricks y cómo encajan estas piezas en un proyecto está explicada en nuestro artículo sobre qué es Databricks.
Qué cambia en la organización cuando se adopta Lakebase
Más allá de las capacidades técnicas, hay tres áreas donde el impacto en el negocio es inmediato.
- La primera es la eliminación de la latencia operativa. Cuando las aplicaciones leen desde Lakebase en lugar de desde una copia sincronizada del Lakehouse, los datos que ven son los mismos que los datos analíticos, sin desfase. Los equipos comerciales trabajan con información actualizada, los modelos de scoring reciben features en tiempo real y los agentes de IA actúan sobre el estado actual del negocio, no sobre una fotografía de hace horas.
- La segunda es la simplificación de la arquitectura. Eliminar una base de datos OLTP externa y los procesos de sincronización asociados reduce el número de sistemas a monitorizar, los puntos de fallo y el trabajo de mantenimiento. Esa reducción de complejidad tiene un valor económico concreto que muchas organizaciones no contabilizan hasta que lo eliminan.
- La tercera es la gobernanza unificada. Con Unity Catalog como única capa de control de acceso para todos los datos, analíticos y operativos, las auditorías de cumplimiento (GDPR, auditorías internas, revisiones de seguridad) dejan de requerir coordinación entre sistemas distintos. Todo el linaje, todos los permisos y toda la trazabilidad están en el mismo lugar.
Lo que están haciendo las empresas con Lakebase
Desde la disponibilidad general de Lakebase, publicada por Databricks, hay casos documentados que ilustran el tipo de valor que se está obteniendo en producción.
- easyJet utilizó Lakebase junto con Databricks Apps para sustituir un entorno heredado de SQL Server con más de diez años de antigüedad. Consolidaron más de cien repositorios Git en dos y redujeron sus ciclos de desarrollo de nueve meses a cuatro, construyendo una aplicación de gestión de ingresos más rápida y fiable con los datos analíticos y operativos en un único entorno.
- Hafnia, empresa del sector marítimo, migró desde un stack de BI estático hacia aplicaciones en tiempo real para sus equipos de flota, finanzas y operaciones comerciales. Con Lakebase como motor transaccional de su portal interno, redujo el tiempo de entrega de aplicaciones listas para producción de dos meses a cinco días.
Según los datos publicados por Databricks en el momento de la GA, desde el lanzamiento de Lakebase en junio de 2025 la adopción ha crecido a un ritmo más del doble que el de su producto de data warehousing, con miles de empresas ejecutando ya cargas de producción sobre sus datos operativos.
Cuándo tiene sentido adoptarlo y cuándo no
Lakebase no es la respuesta correcta en todos los casos. Tiene sentido evaluarlo si Databricks ya es tu plataforma de datos central y mantienes bases de datos OLTP externas cuya única función es servir datos al Lakehouse. También si estás construyendo aplicaciones internas sobre datos que ya viven en Databricks y necesitas persistencia transaccional sin añadir infraestructura. O si estás desarrollando agentes de IA que necesitan acceder a datos operativos en tiempo real.
Si en cambio tu arquitectura de datos no está sobre Databricks, o tus cargas transaccionales son independientes del análisis y no hay beneficio en integrarlas, Lakebase no aporta valor diferencial. La pregunta que importa no es si Lakebase es una tecnología interesante, sino si elimina un problema real que existe hoy en tu arquitectura.
Cómo trabajamos con Lakebase en BertIA
En BertIA llevamos tiempo implementando arquitecturas de datos sobre Databricks para clientes en sectores como el farmacéutico, logístico, energético y de fabricación. La llegada de Lakebase cambia concretamente cómo abordamos proyectos donde el cliente necesita que sus aplicaciones operativas y sus datos analíticos trabajen sobre la misma fuente en tiempo real. Antes, eso requería diseñar y mantener una capa de sincronización. En los casos donde Databricks ya es el centro de la arquitectura, Lakebase elimina esa capa directamente.
Cuando evaluamos si Lakebase encaja en la arquitectura de un cliente, el punto de partida es siempre el mismo: qué sistemas se están sincronizando hoy, con qué latencia, qué problemas genera esa latencia en el negocio y qué coste tiene mantenerla. Esa conversación es más útil que cualquier demo técnica, porque determina si hay un problema real que resolver antes de proponer una solución.
En conclusión
Lakebase no es una actualización incremental. Es la respuesta a un límite arquitectónico que llevaba años obligando a las organizaciones a mantener infraestructuras dobles para poder analizar y operar sobre los mismos datos. Al separar el cómputo del almacenamiento e integrar la capa OLTP dentro del propio Lakehouse, Databricks elimina esa división y permite construir sobre una arquitectura genuinamente unificada.
Si tu empresa ya trabaja con Databricks y estás evaluando cómo reducir la complejidad operativa de tu arquitectura de datos, contacta con el equipo de BertIA para analizar si Lakebase resuelve un problema concreto en tu caso y cuál sería el punto de partida más efectivo.
