Confluent, compañía de IBM, presentó el 4 de noviembre en su conferencia Current 2026 la arquitectura que llama Streamhouse y declaró la disponibilidad general de Lightning Tables en AWS. Con esa entrega, la plataforma de streaming de datos de la compañía queda organizada en cinco pilares: transmitir, conectar, procesar, gobernar y consultar. El último es el que se añade ahora.
Lightning Tables es una capa de servicio de solo lectura que almacena de forma duradera los datos de Apache Kafka y los materializa en tablas que se mantienen al día a medida que llegan los cambios. El resultado es acceso por SQL y por API al estado actual del negocio, con las cifras que publica la compañía: unos 100 milisegundos de frescura del dato, entre 10 y 100 milisegundos de latencia de consulta y más de 1.000 consultas por segundo de caudal.
El resto de los pilares ya existía. Transmitir descansa sobre Kafka y el motor Kora; conectar, sobre más de 150 conectores gestionados; procesar, sobre Apache Flink; y gobernar agrupa linaje, catálogo, calidad, cifrado, gestión de esquemas y control de acceso. A su lado, Tableflow expone los flujos como formatos de tabla abiertos hacia lagos y almacenes analíticos, y el motor de contexto en tiempo real sirve ese estado a agentes de inteligencia artificial a través del protocolo de contexto de modelo.
Lo relevante del anuncio es qué trabajo deja de ser necesario. Consultar el estado actual de un flujo —el saldo de una cuenta, el inventario de una referencia, la última posición de un envío— obligaba hasta ahora a volcar ese estado a un almacén de clave y valor o a una base de datos externa, con su propia tubería que mantener y su propio desfase. Una capa de consulta integrada en la plataforma elimina ese tramo, y con él una de las fuentes habituales de incoherencia entre lo que dice el flujo y lo que ve la aplicación.
La lectura de fondo es que la frontera entre el streaming y la base de datos servida se sigue difuminando, y que los fabricantes compiten por quedarse con las dos cosas. Para quien diseña una arquitectura, eso tiene una cara incómoda: cuanto más resuelve la plataforma, más difícil es sustituirla. Kafka es abierto, pero una capa de consulta propietaria construida encima no lo es, y las aplicaciones que la consulten quedarán escritas contra ella.
Hay dos salvedades concretas que condicionan cualquier plan. La disponibilidad general es solo en AWS, lo que deja fuera por ahora a quien tenga su plataforma de streaming en Azure o en Google Cloud, un caso frecuente en organizaciones españolas con el resto de su infraestructura ya comprometida. Y la capa es de solo lectura: resuelve la consulta del estado, no la escritura transaccional. Antes de rediseñar nada, conviene medir la latencia real con el volumen propio y comparar el coste frente al del almacén externo que hoy cumple esa función.
Más en Dataprix: sección de plataformas de datos de Dataprix
Fuente: Confluent (nota de prensa)
Contenido elaborado con asistencia de inteligencia artificial — Equipo Editorial Dataprix. Verifica la información antes de tomar decisiones.