Durante décadas, los profesionales de datos han luchado con el desafío de administrar bases de datos operativas y analíticas con un enfoque unificado que no introduzca latencia ni degradación del rendimiento.
Los agentes hicieron que el problema fuera estructural. Un sistema que razona continuamente y actúa sobre la base de datos en vivo no puede tolerar un canal entre él y la información que necesita para actuar.
En la Cumbre Data + AI del martes, Databricks anunció dos productos destinados a colapsar esa infraestructura. Lakehouse//RT ofrece latencia de consulta de milisegundos directamente en las tablas Delta e Iceberg gobernadas, eliminando el nivel de servicio dedicado en tiempo real que las empresas han mantenido junto a sus Lakehouse. LTAP, abreviatura de Lake Transactional/Analytical Processing, almacena datos transaccionales nativos de Postgres en formato Delta e Iceberg desde el punto de escritura, eliminando las canalizaciones ETL que han conectado sistemas operativos y analíticos durante décadas.
Reynold Xin, cofundador de Databricks, describió una pila de datos más simple como «el santo grial para los agentes» en una sesión informativa con VentureBeat, argumentando que a medida que los usuarios codifican más aplicaciones, los agentes que razonan analíticamente sobre esas aplicaciones necesitan que la infraestructura subyacente esté fuera del camino para moverse rápidamente.
«Los agentes realmente prefieren una pila mucho más simple, porque pueden moverse mucho más rápido», dijo.
LTAP apuesta por la unificación de la capa de almacenamiento donde HTAP intentó la convergencia de motores
Muchos proveedores han probado varios enfoques a lo largo de décadas para unificar datos analíticos y transaccionales.
En 2014, la firma de analistas Gartner acuñó el término HTAP, un acrónimo de Hybrid Transactional/Analytical Processing como una forma de describir a los proveedores que intentaron unificar los dos tipos de bases de datos. Proveedores, incluido MemSQL (ahora conocido como Tienda única) SAP HANA y Oracle Ola de calor MySQL se encuentran entre los muchos proveedores de HTAP en el mercado.
LTAP es la respuesta de Databricks a HTAP, que utiliza la arquitectura Lakebase para unificar datos en la capa de almacenamiento en lugar del nivel del motor. base del lago es el servicio de base de datos PostgreSQL sin servidor basado en la nube de Databricks que estuvo disponible de forma generalizada en febrero.
«Para nosotros, HTAP es más un fracaso de la industria que un éxito», afirmó Xin.
El enfoque LTAP va a la capa de almacenamiento en lugar de a la capa de consulta. Lakebase anteriormente almacenaba datos de Postgres en formato Postgres en un almacenamiento de objetos, lo que requería una conversión antes de que los motores analíticos de Lakehouse pudieran usarlos de manera eficiente. Con LTAP, los datos transaccionales llegan directamente en formato Delta o Iceberg, compartiendo la misma copia que leen las cargas de trabajo analíticas. Postgres sigue siendo el motor transaccional. Spark y Lakehouse siguen siendo el motor analítico.
Suscríbete y recibe las historias más importantes del día.
Al suscribirte aceptas nuestros términos y condiciones y política de privacidad.
«La cuestión es que, si se utiliza la mejor herramienta para el trabajo a nivel del motor de consultas, simplemente nos aseguramos de que el almacenamiento subyacente sea una única copia de los datos», dijo Xin.
El desafío central de la ingeniería es la latencia. El almacenamiento de objetos tiene tiempos de respuesta en el rango de segundos, demasiado lentos para cargas de trabajo OLTP que requieren un rendimiento inferior a milisegundos. Lakebase maneja esto a través de una capa de almacenamiento en caché entre las instancias informáticas de Postgres y el almacenamiento de objetos. La decisión de diseño clave es dónde ocurre la conversión de columnas: la capacidad de CPU inactiva en esa capa de almacenamiento en caché realiza la conversión de fila a columna antes de que los datos lleguen al almacenamiento de objetos.
«Cuando se convierten datos de fila a columna, normalmente se comprimen más de 10 veces, por lo que ahora se reduce sustancialmente el costo de red de esa capa de almacenamiento en caché básica entre esa capa de almacenamiento en caché y los almacenes de objetos», dijo Xin.
Lakehouse//RT ofrece una latencia de consulta de milisegundos en datos en vivo de Lakehouse sin un nivel de servicio separado
Lakehouse//RT es la respuesta de Databricks al nivel de servicio dedicado en tiempo real: el sistema separado que las empresas han mantenido junto a sus lakehouses para manejar consultas de baja latencia, a costa de copias de datos, gobernanza dividida y complejidad de canalización que los agentes no pueden solucionar. Las capacidades clave de Lakehouse//RT incluyen:
Motor de cálculo Reyden: Diseñado específicamente para servicio de alta concurrencia y baja latencia, Reyden consulta tablas Delta e Iceberg directamente sin mover datos fuera de la casa del lago.
Latencia y rendimiento: Lakehouse//RT ofrece una latencia inferior a 100 ms a 12 000 consultas por segundo, con tiempos de respuesta de tan solo 10 ms en conjuntos de datos más pequeños y un rendimiento hasta 16 veces mejor que las pilas de servicios dedicadas existentes.
Gobernanza y acceso a datos: Cada consulta se ejecuta dentro del marco de gobierno de Unity Catalog sin una capa de permisos separada, sin copias de datos ni canalizaciones de ingesta.
Transformación VB · 14 y 15 de julio · Menlo Park · Capas de contexto agentes
Sus agentes son tan buenos como los datos a los que pueden acceder.
Las sesiones en Transform cubren las arquitecturas RAG que impulsan los sistemas de agentes a escala, incluida cómo las empresas conectan agentes con datos genómicos, clínicos y empresariales en vivo.
Los analistas ven el encuadre agente y el enfoque de formato abierto como los verdaderos diferenciadores.
El problema que abordan ambos productos está bien documentado entre los equipos de datos empresariales, pero los analistas hacen una distinción entre el punto débil y la afirmación específica que hace Databricks.
«Las empresas han tenido HTAP, streaming, almacenes en la nube y tiendas operativas durante años», dijo a VentureBeat Stephanie Walter, líder de práctica de AI Stack en HyperFRAME Research. «Lo que es diferente es el marco agente de la IA».
Walter señaló que los agentes necesitan datos operativos en vivo, contexto histórico, gobernanza, recuperación y reescritura en el mismo flujo de trabajo.
«Ese es un fuerte argumento de arquitectura, pero Lakebase aún tiene que demostrar que puede cumplir con la latencia, confiabilidad y madurez operativa que esperan los CIO», afirmó.
Mike Leone, analista de Moor Insights and Strategy, dijo que el camino hacia una diferenciación genuina es más específico que el concepto de unificación en sí. También señaló que el análisis abierto en un lago de datos es algo que está en juego ahora, y que muchos proveedores brindan algún tipo de servicio.
«La medida menos común es permitir que las escrituras transaccionales también lleguen a formatos abiertos, de modo que la base de datos operativa no esté en una caja propietaria mientras solo la mitad de análisis está abierta», dijo Leone a VentureBeat.
Añadió que el enfoque de formato abierto, junto con Lakehouse//RT que consulta datos en vivo directamente desde el lago, es lo que le da a la arquitectura un caso creíble para retirar una fila completa de sistemas especializados.
La afirmación técnica que enfrentará el mayor escrutinio es también la más central. «La parte que aún me gustaría que sus ingenieros analizaran es cómo ambos motores realmente comparten una copia sin un paso de conversión silencioso que realice la sincronización en el medio», dijo Leone.
Qué significa esto para las empresas
Para los ingenieros de datos que evalúan su pila para cargas de trabajo agentes, la pregunta ya no es qué herramienta mejor ejecutar para cada trabajo, sino si todavía es defendible ejecutar herramientas separadas.
Las empresas que crearon bases de datos operativas separadas, niveles de servicio en tiempo real y lagos analíticos antes podían tratar las brechas entre ellos como una carga de mantenimiento. Los agentes sacan a la luz esas brechas como un riesgo operativo: un sistema que razona a través de los límites de la gobernanza encontrará las inconsistencias más rápido que cualquier equipo humano.
El mercado se está alejando de las capas de servicios especializados más rápido de lo que anticipaban la mayoría de las hojas de ruta de los proveedores. De acuerdo a VB Pulse Q1 2026una encuesta longitudinal de tres rondas de más de 100 organizaciones de empleados, la intención de recuperación híbrida se triplicó del 10,3% al 33,3% durante el trimestre, mientras que la adopción de bases de datos vectoriales independientes disminuyó en todos los proveedores rastreados. La misma lógica de consolidación está afectando ahora al nivel de servicio en tiempo real.
El enfoque tradicional (las mejores herramientas para cada tipo de carga de trabajo, canalizaciones entre ellas) se creó para un consumo analítico a velocidad humana. Las cargas de trabajo de los agentes no toleran esa arquitectura.
«El dolor que señalan, toda la copia y sincronización entre sistemas operativos y analíticos, es real y costoso, y cualquiera que lo ejecute a escala lo siente», dijo Leone.
