Durante décadas, los expertos en datos han lidiado con la dificultad de integrar bases de datos operativas y analíticas en un sistema unificado, sin que ello suponga pérdidas de rendimiento ni aumento de la latencia. Esta problemática estructural se ha revelado aún más crítica con el auge de los agentes de inteligencia artificial, que requieren acceso instantáneo y continuo a datos en vivo para funcionar adecuadamente.
En la reciente conferencia Data + AI Summit, Databricks anunció el lanzamiento de dos productos innovadores diseñados para simplificar radicalmente esta arquitectura. Lakehouse//RT ofrece consultas con latencias de milisegundos directamente sobre tablas Delta e Iceberg bajo gobernanza, eliminando la necesidad de contar con una capa independiente de servicio en tiempo real que las empresas mantenían junto a sus lakehouses. Por otra parte, LTAP (Lake Transactional/Analytical Processing) permite almacenar datos transaccionales nativos de Postgres en formatos Delta e Iceberg desde el momento en que se escriben, eliminando las tradicionales y complejas canalizaciones ETL que durante décadas han conectado sistemas operativos con los analíticos.
Reynold Xin, cofundador de Databricks, calificó este avance como «el santo grial para los agentes», explicando que a medida que muchas aplicaciones incorporan código de usuario, los agentes que analizan datos desde esos entornos necesitan que la infraestructura subyacente sea lo menos intrusiva y más ágil posible para acelerar su funcionamiento. 
LTAP apuesta por la unificación en el almacenamiento frente a la convergencia de motores que intentó HTAP
A lo largo de los años, diversos proveedores han intentado unir los datos analíticos y transaccionales. En 2014, la consultora Gartner acuñó el término HTAP (Hybrid Transactional/Analytical Processing) para describir las estrategias que buscaban esta integración mediante la convergencia de motores de base de datos. Empresas como SingleStore (antes MemSQL), SAP HANA y Oracle con su MySQL Heatwave integran soluciones HTAP.
Sin embargo, LTAP representa la alternativa de Databricks, que utiliza la arquitectura Lakebase para fusionar los datos a nivel de almacenamiento en lugar de a nivel de motor. Lakebase es un servicio de base de datos PostgreSQL sin servidor alojado en la nube que salió a disponibilidad general en febrero.
Según Reynold Xin, «HTAP refleja más un fracaso de la industria que un éxito». La estrategia LTAP consiste en que el almacenamiento sea único: los datos transaccionales se almacenan directamente en formatos Delta o Iceberg, compartiendo la misma copia que utilizan las cargas analíticas. Postgres continúa siendo el motor transaccional, mientras que Spark y Lakehouse siguen siendo los motores analíticos.
Uno de los principales retos técnicos es reducir la latencia. El almacenamiento en objetos tradicionalmente ofrece tiempos de respuesta superiores a un segundo, lo que lo hace inviable para cargas OLTP que requieren un rendimiento en el rango de milisegundos. Lakebase solventa este problema con una capa de caché entre las instancias de cálculo Postgres y el almacenamiento en objetos. La conversión de datos de fila a columna se realiza en esta capa de caché con capacidad de CPU ociosa, lo que además permite una compresión de más de 10 veces, reduciendo considerablemente el coste de red.
Lakehouse//RT: Consultas de milisegundos sin capas de servicio adicionales
El producto Lakehouse//RT de Databricks responde a la problemática de los sistemas dedicados para servicio en tiempo real. Tradicionalmente, las empresas mantenían este sistema aparte para garantizar latencias bajas, lo que generaba duplicidades de datos, gobernanza fragmentada y complejidad en las canalizaciones, que entorpecen el trabajo de los agentes. Las principales características de Lakehouse//RT son:
- Motor de cómputo Reyden: Diseñado para alta concurrencia y baja latencia, permite consultar directamente tablas Delta e Iceberg sin necesidad de mover datos fuera del lakehouse.
- Latencia y rendimiento: Ofrece latencias inferiores a 100 ms a 12.000 consultas por segundo, con tiempos mínimos de apenas 10 ms en conjuntos pequeños y hasta 16 veces mejor rendimiento que arquitecturas existentes.
- Gobernanza y acceso: Todas las consultas se gestionan dentro del marco de gobernanza de Unity Catalog, sin capas de permisos separadas, duplicación de datos ni pipelines adicionales.
El enfoque en agentes y formatos abiertos, claves para la diferenciación
Analistas coinciden en que la problemática que afrontan estos productos es bien conocida, pero subrayan que la visión orientada a agentes de IA y el uso de formatos abiertos marcan la verdadera innovación.
Stephanie Walter, responsable de AI Stack en HyperFRAME Research, explicó a VentureBeat que, aunque las empresas han usado HTAP, sistemas de streaming, almacenes en la nube y bases operativas durante años, lo novedoso es el marco arquitectónico diseñado específicamente para agentes, que requieren datos en vivo, contexto histórico, gobernanza, recuperación y escritura en el mismo flujo de trabajo.
Sin embargo, Walter advierte que Lakebase aún debe demostrar que puede cumplir con las exigencias de latencia, fiabilidad y madurez operativa de los CIOs.
Por su parte, Mike Leone, analista en Moor Insights and Strategy, resalta que la verdadera diferenciación reside en que las escrituras transaccionales aterrizan en formatos abiertos, evitando que la base operativa quede encerrada en sistemas propietarios mientras solo la parte analítica es abierta. Esta característica combinada con Lakehouse//RT, que consulta datos en vivo directamente en el lago, otorga un argumento sólido para eliminar toda una fila de sistemas especializados.
El desafío técnico más importante sigue siendo que ambos motores puedan compartir una única copia de datos sin pasos intermedios invisibles de conversión y sincronización, un punto que los expertos esperan que los ingenieros de Databricks puedan demostrar de forma clara.
Impacto para las empresas: hacia una arquitectura de datos simplificada
Los ingenieros de datos que evalúan infraestructuras para cargas de trabajo con agentes de IA deben replantearse si aún tiene sentido mantener varias herramientas especializadas para cada función. Hasta ahora, las empresas que mantenían bases de datos operativas, capas de servicio en tiempo real y lakehouses analíticos habían asumido las brechas entre estos sistemas como una carga de mantenimiento.
Sin embargo, los agentes evidencian que estas divisiones representan riesgos operativos reales, ya que un sistema que razona a través de límites de gobernanza detectará inconsistencias mucho más rápido que un equipo humano.
El mercado está avanzando hacia la desaparición de capas de servicio en tiempo real especializadas más rápido de lo que la mayoría de las hojas de ruta de proveedores anticipaban. Según un estudio longitudinal de más de 100 organizaciones publicado en VB Pulse Q1 2026, la intención de adoptar recuperación híbrida se triplicó en un trimestre, mientras que el uso de bases vectoriales independientes, una solución popular, decreció en todos los proveedores.
Este cambio se debe a que la arquitectura tradicional, basada en las mejores herramientas para cada carga y canales entre ellas, responde a un consumo analítico a velocidad humana, que las cargas de agentes no pueden tolerar.
Mike Leone concluye que «el problema de las copias y sincronizaciones entre sistemas operativos y analíticos es real, costoso y palpable para cualquiera que lo gestione a gran escala»; y que soluciones como las de Databricks podrían marcar un punto de inflexión hacia arquitecturas más integradas y eficientes.
