Lakehouse RT: Rendimiento en Milisegundos sobre Delta sin Abandonar el Lakehouse
- Miguel Diaz
- 16 jun, 2026
- 10 Mins de lectura
- Databricks
Tu lakehouse guarda todos los datos. Tus pipelines de streaming los actualizan en segundos. Pero cuando el equipo de producto pide una dashboard que cargue en 50ms con 500 usuarios concurrentes, tus Data Engineers hacen lo que todos hacen: montan un ClickHouse aparte, sincronizan los datos, duplican el schema, y pagan otra factura.
Ese patrón — que se repite en decenas de empresas — crea tres problemas reales: datos duplicados que se desincronizamos, gobernanza fragmentada entre dos sistemas, y costos dobles de infraestructura. Lakehouse//RT existe para cortar ese ciclo en la raíz.
¿Qué es Lakehouse//RT?
Milisegundos reales
Rendimiento en milisegundos a alta concurrencia, no solo en queries aisladas
Delta/Iceberg nativo
Lee directamente desde Unity Catalog. Sin copias, sin ETLs de sincronización
Motor vectorizado total
Motor nativo reconstruido, alineado con Photon para un pipeline vectorizado end-to-end
Gobernanza unificada
Unity Catalog aplica los mismos ACLs, linaje y auditoría que en el resto del lakehouse
Lakehouse//RT es un nuevo tipo de warehouse que aparece en el selector de SQL warehouses de Databricks, junto a SQL Classic, Pro y Serverless. A diferencia de sus hermanos —optimizados para analítica batch y workloads ad-hoc— Lakehouse//RT está construido desde cero para latencia en milisegundos a alta concurrencia.
La diferencia técnica clave: su motor de ejecución fue reconstruido nativamente y está alineado con Photon para crear un pipeline vectorizado completo, de extremo a extremo. No es una extensión de un warehouse existente — es una arquitectura diferente para un caso de uso diferente.
Entró en Gated Beta en DAIS 2026 y está disponible en AWS, Azure y GCP donde corre SQL Serverless (GovCloud aún no está soportado).
El problema: el stack fragmentado que todos construyen hoy
La arquitectura que cada equipo termina construyendo
Los usuarios necesitan latencia de milisegundos
Las dashboards operacionales, aplicaciones de analítica embebida y herramientas de observabilidad exigen respuestas en decenas de milisegundos. Un lakehouse analítico tradicional responde en segundos — demasiado lento para estas cargas.
La solución típica: montar un sistema adicional
Los equipos terminan añadiendo ClickHouse, StarRocks, Snowflake, Fabric RTI o BigQuery encima del lakehouse para servir las queries rápidas. El resultado: duplicas los datos, fragmentas la gobernanza y pagas dos facturas.
ClickHouse
Stack paralelo + sync de datos
StarRocks
Ingesta duplicada + ops separadas
Snowflake
General-purpose, no optimizado para ms
Fabric RTI
Ecosistema separado, fuera del lakehouse
El costo real: no solo la factura extra. Es el pipeline de sincronización que hay que mantener, el desfase de datos entre sistemas, la doble configuración de permisos y el riesgo de inconsistencias en producción. Lakehouse//RT elimina todo eso — consultas en milisegundos directamente donde ya viven los datos.
Cómo funciona: el nuevo warehouse picker
Tipos de warehouse en Databricks SQL
SQL Classic
Analítica estándar en tu cuenta cloud. Startup en minutos.
SQL Pro
Photon + Predictive IO. Para workloads analíticos intensivos.
SQL Serverless
Startup ~2–6s. IWM + Photon. Alta concurrencia analítica.
Lakehouse//RT NUEVO
Motor vectorizado reconstruido. Photon-aligned. Delta/Iceberg nativo. Alta concurrencia real.
El motor: pipeline vectorizado end-to-end
A diferencia de los warehouses analíticos tradicionales que tienen cuellos de botella en la ejecución row-by-row, Lakehouse//RT mantiene todo el pipeline en formato columnar vectorizado: desde la lectura de Parquet/Delta en almacenamiento hasta la entrega del resultado. Esto, combinado con la alineación con Photon, es lo que habilita la latencia en milisegundos sin sacrificar la capacidad de leer directamente desde el lakehouse.
Tres casos de uso que lo justifican
Analítica operacional
Dashboards de operaciones, KPIs en tiempo real, métricas de negocio con datos frescos. Aplicaciones que necesitan consultar el estado actual de la operación con latencia inferior a 100ms y decenas o cientos de usuarios concurrentes.
Reemplaza los stacks de ClickHouse montados para “solo esta dashboard operacional”.
BI serving embebido
Analítica embebida en productos — donde el usuario final no es un analista interno sino un cliente del producto. Estos contextos exigen cargas instantáneas y alta concurrencia simultánea. AI/BI hoy; Power BI y Tableau via JDBC+ODBC pronto.
El caso donde las dashboards “lentas para usuarios” se resuelven con más hardware — hasta ahora.
Observabilidad y monitoreo
Plataformas de observabilidad internas, sistemas de alertas basados en datos, monitoreo de calidad de datos en tiempo real. Casos donde necesitas correlacionar eventos de log, métricas de workloads y datos de tablas con latencia mínima.
Synergía natural con Genie ZeroOps para correlación de fallas en tiempo real.
Lo que Lakehouse//RT elimina de tu arquitectura
Antes vs. después de Lakehouse//RT
SIN Lakehouse//RT
Datos duplicados entre lakehouse y serving layer
Gobernanza fragmentada: dos sistemas de ACLs
Segunda factura (ClickHouse, StarRocks, etc.)
Pipeline de sync que se rompe y desincroniza
Ops separadas para dos plataformas distintas
CON Lakehouse//RT
Una sola copia: Delta/Iceberg en Unity Catalog
Gobernanza única: Unity Catalog aplica en todo
Una factura: el warehouse es parte de Databricks
Sin pipelines de sincronización que mantener
Un solo plano de operaciones y monitoreo
Disponibilidad y herramientas de BI
Disponibilidad por nube
Lakehouse//RT está en Gated Beta en AWS y Azure. Disponible también en GCP donde corre SQL Serverless. GovCloud aún no está soportado — las fechas para entornos regulados se anunciarán en el roadmap oficial.
Herramientas de BI soportadas
Hoy disponible: AI/BI de Databricks (Genie + dashboards nativas). Próximamente: Power BI y Tableau conectarán via JDBC+ODBC, habilitando el mismo rendimiento en milisegundos desde herramientas de BI existentes.
Preguntas frecuentes
Lakehouse//RT cierra una de las últimas brechas del lakehouse moderno: la velocidad de serving para usuarios concurrentes. Hasta ahora, la respuesta a “necesito dashboards que carguen en milisegundos” era siempre “monta otro sistema”. Con Lakehouse//RT, esa respuesta cambia a “elige otro tipo de warehouse en el mismo picker”.
Para equipos que hoy mantienen stacks de ClickHouse o StarRocks sincronizados con Databricks, este es el producto que esperaban: el mismo lakehouse, los mismos datos, los mismos permisos — a la velocidad que exigen las aplicaciones de producción.