Hace cinco años, Databricks acuñó el término “data lakehouse” para describir un nuevo tipo de arquitectura de datos que combina un lago de datos con un almacén de datos. Este término y arquitectura de datos ahora son comunes en toda la industria de datos para cargas de trabajo analíticas.
Ahora, Databricks busca una vez más crear una nueva categoría con su servicio Lakebase, que ahora está disponible de forma generalizada. Mientras que la construcción de data lakehouse se ocupa de bases de datos OLAP (procesamiento analítico en línea), Lakebase se ocupa de OLTP (procesamiento de transacciones en línea) y bases de datos operativas. El servicio Lakebase está en desarrollo desde junio de 2025 y se basa en la tecnología Databricks obtenida mediante la adquisición de Proveedor de base de datos PostgreSQL Neon. Se mejoró aún más en octubre de 2025 con la adquisición de Mooncake, que trajo características para ayudar a unir PostgreSQL con formatos de datos de Lakehouse.
Lakebase es una base de datos operativa sin servidor que representa un replanteamiento fundamental de cómo funcionan las bases de datos en la era de los agentes autónomos de IA. Los primeros usuarios, incluidos easyJet, Hafnia y Warner Music Group, están reduciendo los tiempos de entrega de aplicaciones entre un 75 y un 95 %, pero una innovación arquitectónica más profunda posiciona a las bases de datos como una infraestructura efímera de autoservicio que los agentes de IA pueden aprovisionar y gestionar sin intervención humana.
Este no es simplemente otro servicio administrado de Postgres. Lakebase trata las bases de datos operativas como computación liviana y desechable que se ejecuta en un lago de datos, en lugar de sistemas monolíticos que requieren una cuidadosa planificación de la capacidad y supervisión del administrador de la base de datos (DBA).
“Realmente, para que despegue la tendencia de la codificación flutter, es necesario que los desarrolladores crean que realmente pueden crear nuevas aplicaciones muy rápidamente, pero también es necesario que el personal central de TI, o DBA, se sienta cómodo con el tsunami de aplicaciones y bases de datos”, dijo Reynold Xin, cofundador de Databricks, a VentureBeat. “Las bases de datos clásicas simplemente no se adaptan a esto porque no pueden permitirse el lujo de poner un DBA por base de datos y por aplicación”.
Entrega un 92 % más rápida: de dos meses a cinco días
Las cifras de producción demuestran un impacto inmediato más allá de la visión de aprovisionamiento de agentes. Hafnia redujo el tiempo de entrega de las aplicaciones listas para producción de dos meses a cinco días (o un 92%) al utilizar Lakebase como motor transaccional para su portal de operaciones internas. La compañía naviera ha ido más allá de los informes de BI estáticos hacia aplicaciones comerciales en tiempo real para flujos de trabajo financieros, comerciales y de flotas.
EasyJet consolidó más de 100 repositorios Git en solo dos y redujo los ciclos de desarrollo de nueve a cuatro meses (una reducción del 56%) mientras construía un centro de gestión de ingresos basado en web en Lakebase para reemplazar una aplicación de escritorio de una década de antigüedad y uno de los entornos SQL Server heredados más grandes de Europa.
Warner Music Group está trasladando conocimientos directamente a los sistemas de producción utilizando la base unificada, mientras que Quantum Capital Group la utiliza para mantener datos consistentes y controlados para identificar y evaluar inversiones en petróleo y gas, eliminando la duplicación de datos que anteriormente obligaba a los equipos a mantener múltiples copias en diferentes formatos.
La aceleración es el resultado de la eliminación de dos cuellos de botella importantes: la clonación de bases de datos para entornos de prueba y el mantenimiento de canales ETL para la sincronización de datos operativos y analíticos.
Arquitectura técnica: por qué esto no es solo Postgres administrado
Las bases de datos tradicionales combinan almacenamiento y computación: las organizaciones aprovisionan una instancia de base de datos con almacenamiento adjunto y escala, agregando más instancias o almacenamiento. AWS Aurora innovó al separar estos niveles mediante almacenamiento propietario, pero el almacenamiento permaneció bloqueado dentro del ecosistema de AWS y no era accesible de forma independiente para su análisis.
Lakebase lleva la separación del almacenamiento y la computación a su conclusión lógica al colocar el almacenamiento directamente en el lago de datos. Básicamente, la capa informática ejecuta PostgreSQL básico, manteniendo total compatibilidad con el ecosistema de Postgres, pero cada escritura va al almacenamiento del lago en formatos que Spark, Databricks SQL y otros motores de análisis pueden consultar inmediatamente sin ETL.
“La idea técnica única fue que los lagos de datos separan el almacenamiento de la computación, lo cual fue excelente, pero necesitamos introducir capacidades de gestión de datos como la gobernanza y la gestión de transacciones en el lago de datos”, explicó Xin. “En realidad, no somos tan diferentes del concepto de la casa del lago, pero estamos construyendo computación efímera y liviana para bases de datos OLTP”.
Databricks construyó Lakebase con la tecnología obtenida de la adquisición de Neon. Pero Xin enfatizó que Databricks ha ampliado significativamente las capacidades originales de Neon para crear algo fundamentalmente diferente.
“No tenían experiencia empresarial ni escalabilidad en la nube”, dijo Xin. “Hemos reunido la nueva idea arquitectónica del equipo de Neon con la solidez de la infraestructura de Databricks y las hemos combinado. Ahora hemos creado una plataforma súper escalable”.
Desde cientos de bases de datos hasta millones creadas para la IA de las agencias
Xin describió una visión directamente relacionada con la economía de las herramientas de codificación de IA que explica por qué la construcción de Lakebase es importante más allá de los casos de uso actuales. A medida que los costos de desarrollo caen en picado, las empresas pasarán de comprar cientos de aplicaciones SaaS a crear millones de aplicaciones internas personalizadas.
“A medida que disminuya el costo del desarrollo de software, lo que estamos viendo hoy debido a las herramientas de codificación de IA, esto pasará de la proliferación de SaaS en los últimos 10 a 15 años a la proliferación del desarrollo interno de aplicaciones”, dijo Xin. “En lugar de crear quizás cientos de aplicaciones, con el tiempo crearán millones de aplicaciones personalizadas”.
Esto crea un problema de gestión de flotas que es imposible con los enfoques tradicionales. No se pueden contratar suficientes administradores de bases de datos para aprovisionar, monitorear y solucionar problemas manualmente en miles de bases de datos. La solución de Xin: tratar la gestión de bases de datos en sí misma como un problema de datos en lugar de un problema operativo.
Lakebase almacena toda la telemetría y los metadatos (rendimiento de consultas, utilización de recursos, patrones de conexión, tasas de error) directamente en Lakehouse, donde se pueden analizar utilizando herramientas estándar de ingeniería y ciencia de datos. En lugar de configurar paneles en herramientas de monitoreo específicas de bases de datos, los equipos de datos consultan datos de telemetría con SQL o los analizan con modelos de aprendizaje automático para identificar valores atípicos y predecir problemas.
“En lugar de crear un panel para cada 50 o 100 bases de datos, puedes mirar el gráfico para saber si algo se ha comportado mal”, explicó Xin. “La gestión de bases de datos será muy similar a un problema de análisis. Se observan valores atípicos, se observan tendencias, se intenta comprender por qué suceden las cosas. Así es como se gestiona a escala cuando los agentes crean y destruyen bases de datos mediante programación”.
Las implicaciones se extienden a los propios agentes autónomos. Un agente de IA que experimente problemas de rendimiento podría consultar datos de telemetría para diagnosticar problemas, tratando las operaciones de la base de datos como una tarea analítica más en lugar de requerir conocimientos especializados de DBA. La gestión de bases de datos se convierte en algo que los agentes pueden hacer ellos mismos, utilizando las mismas capacidades de análisis de datos que ya tienen.
Qué significa esto para los equipos de datos empresariales
La construcción de Lakebase señala un cambio fundamental en la forma en que las empresas deberían pensar en las bases de datos operativas: no como una infraestructura valiosa y cuidadosamente administrada que requiere DBA especializados, sino como recursos efímeros de autoservicio que escalan mediante programación como la computación en la nube.
Esto es importante independientemente de que los agentes autónomos se materialicen tan rápido como predice Databricks, porque el principio arquitectónico subyacente (tratar la gestión de bases de datos como un problema analítico en lugar de un problema operativo) cambia las habilidades y las estructuras de equipo que las empresas necesitan.
Los líderes de datos deben prestar atención a la convergencia de datos operativos y analíticos que se produce en toda la industria. Cuando los motores de análisis pueden consultar inmediatamente las escrituras en una base de datos operativa sin ETL, los límites tradicionales entre los sistemas transaccionales y los almacenes de datos se vuelven borrosos. Esta arquitectura unificada reduce la sobrecarga operativa que supone mantener sistemas separados, pero también requiere repensar las estructuras de los equipos de datos construidos alrededor de estos límites.
Cuando se lanzó Lakehouse, los competidores rechazaron el concepto antes de adoptarlo ellos mismos. Xin espera la misma trayectoria para Lakebase.
“Tiene sentido separar el almacenamiento y la computación y poner todo el almacenamiento en el lago; permite muchas capacidades y posibilidades”, dijo.
