Streamhouse es la nueva palabra de moda. Esto es lo que realmente importa.

Por Andrew Tan

La palabra que nadie definió

Estaba en un panel el mes pasado cuando alguien usó la palabra “streamhouse” cinco veces en dos minutos. Lo decía con total seriedad. Afirmaba que era “el mayor cambio en la arquitectura de datos desde el lakehouse”. Decía que “colapsaría la frontera entre streaming y analítica”. Y que los equipos que no lo adoptaran estarían “manteniendo infraestructuras batch legacy” en menos de dieciocho meses.

Después del panel, le pregunté qué era realmente un streamhouse.

Hizo una pausa. Luego dijo: “Es cuando tu plataforma de streaming y tu almacén se convierten en la misma cosa”. Le pedí un ejemplo. Respondió: Kafka con Iceberg. Le pregunté en qué se diferenciaba de lo que ya hace Flink. Contestó que el streamhouse era “nativo”. Le pregunté qué significaba “nativo” en ese contexto. Dijo que significaba que no necesitas un trabajo separado para mover datos del stream al almacén. Le pregunté qué ocurre cuando el stream necesita ser reproducido, rellenado o unido a una tabla de dimensión de cambio lento. Respondió que esos eran “detalles de implementación”.

Era un vendedor. Estaba vendiendo algo. Pero la palabra ya está suelta en la naturaleza, y la he escuchado de arquitectos de datos, responsables de plataformas e incluso de un CTO que me dijo que su estrategia para 2027 era “streamhousear toda la pila analítica”.

Así que hagamos lo que el marketing no hace: definir la cosa, separar el cambio real del reempaquetado y averiguar si esto es una categoría que deberías tener en cuenta o simplemente una nueva etiqueta para la complejidad que ya tienes.

Lo que se supone que significa “streamhouse”

El término proviene de un grupo de trabajo anunciado a principios de este año por Confluent, Aiven, Redpanda, StreamNative y Ververica. La propuesta es sencilla: los datos de streaming y los datos analíticos han vivido en sistemas separados durante demasiado tiempo. Kafka maneja el stream. Snowflake maneja la analítica. Construyes un pipeline entre ambos. El pipeline se rompe. Todos culpan al otro equipo.

La propuesta del streamhouse es unificarlos. Los datos de streaming llegan a formatos de tabla abiertos —Iceberg, Delta Lake, Paimon— en el momento en que arriban. Los motores de consulta leen esas tablas directamente. Sin trabajo de ETL. Sin sincronización batch. Sin “zona de aterrizaje” que se quede obsoleta entre ejecuciones. El stream es la tabla. La tabla es el stream.

Confluent lo llama Tableflow. Aiven lo llama Aiven Streams. La marca exacta cambia según el proveedor, pero la arquitectura es consistente:

• Los eventos llegan a una capa de streaming (Kafka, Redpanda, Pulsar).
• Un motor de streaming (Flink, Spark Structured Streaming o un runtime específico del proveedor) los escribe de forma incremental en un formato de tabla abierto.
• Los motores de consulta (Trino, DuckDB, Snowflake, BigQuery) leen la tabla como si fuera una tabla normal de almacén.
• La tabla se “actualiza continuamente” en lugar de “refrescarse periódicamente”.

Esto no es una estafa. Hay un logro técnico real. Conseguir que un pipeline de streaming produzca archivos de tabla consultables en casi tiempo real, con evolución de esquema, compactación y aislamiento de instantáneas, es genuinamente difícil. Los equipos que están construyendo esto merecen reconocimiento.

Pero la arquitectura no es nueva. Es un refinamiento de algo que Flink, Kinesis Analytics e incluso algunos pipelines personalizados de Kafka a S3 llevan años haciendo. Lo nuevo es el paraguas de marketing: la palabra “streamhouse”, el grupo de trabajo y la promesa de que este patrón elimina la necesidad de sistemas batch y de streaming separados.

Esa última parte es la exageración.

Lo que cambia — y lo que no

Separemos lo real de lo aspiracional.

Lo que realmente mejora:

• La latencia hasta los datos consultables se reduce. Si ejecutas una sincronización batch cada hora, pasar a micro-batching continuo o a streaming real la baja a segundos o minutos. Para casos de uso donde la frescura importa —detección de fraude, dashboards operativos, precios en tiempo real— esto es una mejora genuina.
• La evolución de esquema es más limpia. Los formatos de tabla abiertos gestionan los cambios de esquema mejor que la mayoría de los pipelines personalizados de streaming a almacén. Añadir una columna no requiere un script de migración. Cambiar el nombre de un campo queda registrado en los metadatos. Esto reduce los incidentes de “quién rompió el dashboard”.
• Una sola capa de almacenamiento, menos copias. Si el equipo de analítica puede consultar los mismos archivos Iceberg que produce tu pipeline de streaming, no necesitas una extracción separada al almacén. Menos copias significan menos trabajos de sincronización, menos ventanas de consistencia y menos lugares donde los datos puedan divergir.

Lo que se mantiene exactamente igual:

• Orquestación. Un streamhouse no elimina la necesidad de coordinar trabajos, dependencias y reintentos. Si tu pipeline de streaming alimenta un modelo dbt que alimenta un dashboard, ese DAG sigue necesitando gestión. El streamhouse reemplaza el paso de extracción batch. No reemplaza la capa de orquestación.
• Backfills y reproducciones. Cuando un error corrompe tres días de datos transmitidos, necesitas rebobinar el log y reprocesar. El formato de tabla del streamhouse lo hace posible. No lo hace fácil. Sigues necesitando gestionar offsets de consumidores, manejar cambios de esquema que ocurrieron en medio del stream y verificar que los datos reprocesados coincidan con lo que los sistemas downstream ya vieron.
• Flujos entre sistemas. La mayoría de los pipelines reales tocan más de un sistema. Un stream puede disparar una llamada a una API, actualizar una caché, escribir en una base de datos y producir una notificación. El streamhouse maneja la ruta analítica. No maneja la ruta operativa. Sigues necesitando un runtime que pueda coordinar entre sistemas con modelos de consistencia y modos de fallo diferentes.
• Estructura de costes. La infraestructura de streaming es siempre activa. Un trabajo batch que se ejecuta diez minutos cada hora cuesta diez minutos de cómputo por hora. Un trabajo de streaming que se ejecuta continuamente cuesta sesenta. El streamhouse desplaza el coste de los trabajos de sincronización al cómputo de streaming. Si eso es más barato depende de tu volumen, tus patrones de consulta y lo bien que ajustes la compactación.

El streamhouse mejora el almacenamiento y la consultabilidad de los datos de streaming. No elimina la necesidad de un runtime que gestione el trabajo operativo complejo alrededor de esos datos.

La ilusión de la tabla continua

La idea más seductora del discurso del streamhouse es la “tabla continua”. Es una tabla que nunca se vuelve obsoleta. La consultas y obtienes los datos más recientes. Sin trabajo batch. Sin esperas. La tabla está viva.

Es un modelo mental poderoso. También es ligeramente engañoso.

Una tabla continua no es un único objeto que se actualiza en su lugar. Es una secuencia de instantáneas, cada una representando la tabla en un momento concreto. Cuando la consultas, estás leyendo una de esas instantáneas. El motor de consulta elige la más reciente que conoce. El motor de streaming está constantemente añadiendo nuevos archivos y confirmando nuevas instantáneas.

Esto importa porque la brecha entre “llegó el último evento” y “la última instantánea es consultable” no es cero. Depende de:

• Frecuencia de confirmación. ¿Con qué frecuencia escribe el motor de streaming una nueva instantánea? ¿Cada segundo? ¿Cada minuto? Cuanto más rápido, mayor sobrecarga de metadatos.
• Retraso de compactación. La tabla acumula archivos pequeños. Las consultas se ralentizan. Alguien —o algún trabajo programado— tiene que compactar esos archivos en otros más grandes. Durante la compactación, el comportamiento de las consultas puede cambiar.
• Consistencia del catálogo. El motor de consulta se entera de las nuevas instantáneas a través de un catálogo. Si el catálogo es eventualmente consistente —y la mayoría lo son— una consulta podría leer una instantánea que está treinta segundos por detrás del stream real. Treinta segundos no es tiempo real. Es casi tiempo real disfrazado de tiempo real.

La tabla continua es una abstracción útil. Pero sigue siendo una abstracción sobre un proceso de lotes de micro-lotes. Los archivos son discretos. Las instantáneas son discretas. La frescura está limitada por intervalos de confirmación, programaciones de compactación y latencia del catálogo. Llamarlo “continuo” oscurece la realidad de la ingeniería, que es: lotes más pequeños, confirmaciones más rápidas, los mismos problemas de coordinación.

Dónde los equipos terminan uniendo runtimes

Este es el escenario que el marketing del streamhouse no te muestra:

Tienes un pipeline de streaming que escribe eventos en una tabla Iceberg. Tu equipo de analítica la consulta con Trino. Tu equipo de ML la lee con Spark. Tu equipo operativo necesita disparar una alerta cuando ocurre un patrón de evento específico —no después de que el evento aterrice en la tabla, sino cuando llega al stream.

El streamhouse maneja las rutas de analítica y ML. Pero la alerta operativa necesita ejecutarse contra el stream mismo, antes de que el evento se confirme en una instantánea de tabla. Así que levantas un trabajo Flink separado para procesar el stream en bruto. Ahora tienes dos runtimes: uno para la ruta de tabla y otro para la ruta operativa.

Luego el negocio pide un informe semanal que reconcilie los datos transmitidos con los datos batch de tu sistema ERP. Los datos del ERP no llegan en un stream. Llegan como un volcado CSV diario. Así que construyes un trabajo batch que lee el CSV, lo une a la tabla Iceberg y genera el informe. Ahora tienes tres runtimes.

Entonces alguien descubre que el pipeline de streaming produjo datos erróneos durante seis horas el martes pasado por una deriva de esquema. Necesitas rebobinar el stream, corregir la lógica y reproducir. Pero la reproducción tiene que generar exactamente las mismas instantáneas de tabla que los sistemas downstream ya vieron, o la ejecución de entrenamiento del equipo de ML será inconsistente. Así que coordinas la reproducción con el pipeline del equipo de ML. Ahora estás haciendo orquestación de runtime entre cuatro sistemas.

El streamhouse resolvió el problema de “cómo consulto mi stream”. No resolvió el problema de “cómo coordino múltiples runtimes con semánticas diferentes”. Ese problema sigue siendo tuyo.

El marco de decisión honesto

Si estás evaluando si el patrón streamhouse tiene sentido para tu equipo, no empieces por el diagrama de arquitectura. Empieza por lo que realmente estás intentando hacer.

Usa un streamhouse cuando:

• Tu caso de uso principal es analítica o ML sobre datos que llegan continuamente y tu sincronización batch actual es el cuello de botella.
• Ya ejecutas Kafka (o Redpanda, o Pulsar) y estás cansado de mantener pipelines separados para mover esos datos a un almacén.
• Tus patrones de consulta son compatibles con formatos de tabla abiertos —lecturas columnares, predicate pushdown, aislamiento de instantáneas— y no estás intentando hacer disparadores operativos por debajo del segundo.
• Tienes el equipo necesario para gestionar compactación, consistencia de catálogo y evolución de esquema a velocidad de streaming.

No uses un streamhouse cuando:

• Tu caso de uso de “streaming” es en realidad un trabajo batch que se ejecuta cada quince minutos. El streamhouse no es gratis. Si nadie necesita los datos más rápido de quince minutos, estás pagando cómputo continuo por un valor intermitente.
• Necesitas disparadores operativos —llamadas a API, actualizaciones de caché, notificaciones— que deben activarse en el momento de llegada del evento, no en la confirmación de la tabla. El streamhouse es un patrón analítico, no un patrón operativo.
• Tu equipo ya tiene dificultades con las operaciones de formatos de tabla abiertos. El streamhouse añade velocidad de streaming a esas operaciones. Si la compactación y la gestión del catálogo ya son dolorosas, hacerlas más rápidas no las hace más fáciles.
• Esperas que reemplace tu capa de orquestación. No lo hará. Seguirás necesitando algo que gestione dependencias, reintentos, backfills y flujos entre sistemas.

El streamhouse es un patrón de almacenamiento y consulta. No es un patrón de runtime. Si tus problemas son de almacenamiento y consulta —datos obsoletos, retraso de sincronización, demasiadas copias— vale la pena evaluarlo. Si tus problemas son de runtime —coordinación, recuperación de fallos, semánticas entre sistemas— el streamhouse no ayuda y puede añadir complejidad.

Lo que los proveedores realmente están vendiendo

No creo que el grupo de trabajo del streamhouse esté siendo deshonesto. Creo que están siendo selectivos. Están mostrando los casos de uso donde el patrón brilla —analítica en tiempo real, feature stores de ML continuos, dashboards operativos— y omitiendo silenciosamente aquellos donde no funciona.

Lo que realmente están vendiendo es un cambio en el centro de gravedad. Durante la última década, el almacén era el centro del universo de datos. Todo fluía hacia él. La propuesta del streamhouse dice que el stream es el centro y que el almacén es solo uno de muchos consumidores.

Este es un cambio significativo para algunas organizaciones. Si tu negocio es impulsado por eventos —detección de fraude, IoT, trading en tiempo real— el modelo stream-first tiene sentido. Pero la mayoría de las organizaciones no están impulsadas por eventos. Están impulsadas por calendarios. Ejecutan informes. Actualizan dashboards. Reentrenan modelos por la noche. Para estos equipos, mover el centro de gravedad al stream es una solución en busca de un problema.

Los proveedores lo saben. Por eso el marketing enfatiza “a prueba de futuro” y “arquitectura de datos moderna” en lugar de mejoras operativas concretas. El streamhouse se posiciona como una evolución inevitable, como lo fueron la Cloud o el lakehouse antes. El subtexto es: si no estás haciendo esto, te estás quedando atrás.

Tal vez. Pero ¿quedarse atrás de qué? Si tus pipelines batch son fiables, tus interesados están satisfechos y tus costes son predecibles, adoptar un streamhouse porque un proveedor dice que es inevitable no es modernización. Es arquitectura por FOMO.

Dónde encajamos nosotros

En layline.io no vendemos un streamhouse. Vendemos un runtime que maneja tanto batch como streaming en el mismo pipeline, sobre la infraestructura que ya tienes.

La razón por la que esto importa es que muchos equipos están evaluando el streamhouse porque quieren que batch y streaming coexistan sin mantener dos pilas separadas. Ese es un problema real. Pero el streamhouse lo resuelve unificando el almacenamiento alrededor del stream. Nosotros lo resolvemos unificando el runtime alrededor del Workflow.

Si tu equipo de analítica necesita una tabla de almacén y tu equipo de operaciones necesita un disparador de stream, ambas rutas pueden ejecutarse a través de la misma lógica de pipeline, la misma observabilidad y la misma recuperación de fallos. El formato de almacenamiento se convierte en una elección de configuración —Iceberg cuando ayuda, Parquet cuando no, un bus de mensajes cuando necesitas latencia operativa— en lugar de un compromiso arquitectónico.

El streamhouse es un patrón útil para un conjunto específico de problemas. No es una arquitectura universal ni un reemplazo del runtime operativo que mantiene tus pipelines funcionando a las 2 de la mañana. Los equipos que tienen éxito con él son aquellos que lo adoptan por las razones correctas —latencia de consulta, menor sobrecarga de sincronización, evolución de esquema más limpia— y no esperan que resuelva problemas que nunca estuvo diseñado para tocar.

La palabra de moda desaparecerá. La tecnología subyacente —ingestión continua en formatos de tabla abiertos— se quedará y mejorará. La pregunta es si tu equipo lo necesitaba antes de que el marketing te dijera que lo necesitabas.

Si tu equipo está intentando separar la señal del streamhouse del ruido —o si estás buscando un runtime que maneje batch y streaming sin obligarte a elegir una religión de almacenamiento— ponte en contacto. Hemos ayudado a equipos a evaluar exactamente este trade-off, y la respuesta suele ser más simple de lo que sugieren los diagramas de arquitectura.

Andrew Tan es un emprendedor en serie y fundador de layline.io, que construye infraestructura de procesamiento de datos empresarial que maneja cargas de trabajo batch y en tiempo real a escala.