Real-Time AI Lakehouse
A lakehouse architecture that ingests data as a **streaming first-class citizen** rather than as a periodic batch append. Built on a Log-Structured Merge-tree (LSM) layer over object storage (Apache Paimon is the reference implementation), the pattern unifies streaming writes from Apache Flink/Kafka, columnar storage on S3-compatible object stores, and analytical reads from Trino/StarRocks — all on the same physical table. Outputs Iceberg-compatible snapshots so analytical engines that don't natively speak Paimon read the same data without an ETL hop.
Definition
A lakehouse architecture that ingests data as a **streaming first-class citizen** rather than as a periodic batch append. Built on a Log-Structured Merge-tree (LSM) layer over object storage (Apache Paimon is the reference implementation), the pattern unifies streaming writes from Apache Flink/Kafka, columnar storage on S3-compatible object stores, and analytical reads from Trino/StarRocks — all on the same physical table. Outputs Iceberg-compatible snapshots so analytical engines that don't natively speak Paimon read the same data without an ETL hop.
Traditional lakehouse table formats (Iceberg, Delta, Hudi) were designed primarily for batch ingestion, with streaming patched on later. AI workloads — agentic memory, real-time embedding pipelines, live-dashboard analytics over user interactions — generate continuous events at hundreds-of-thousands-to-millions of rows per second, exposing the write-amplification ceiling of copy-on-write formats. Real-Time AI Lakehouse architectures keep ingestion under sub-minute latency *and* keep analytical engines reading the same data via an Iceberg-shaped read surface.
Continuous CDC ingestion into the analytical layer for AI feature engineering, agentic-memory write paths where thousands of agents append context per second, real-time embedding pipelines feeding both training and online inference, unified streaming + batch analytics where the same table must serve both shapes.
Recent developments
- Apache Fluss + Paimon = the tiered Streamhouse pattern. Fluss delivers sub-second real-time data for Flink (reducing state bloat); Paimon is the streaming lakehouse format with ACID + minute-level latency. Together: Fluss handles "right now," Paimon handles "recent past + history." Write once into Fluss, tier seamlessly to Paimon. Per Apache Fluss + Paimon docs.
- Alibaba 3 PB production deployment processing 40 GB/s. Real-world production reference: Fluss + Iceberg architecture running at 3 PB scale with 40 GB/s throughput. The Streamhouse pattern is validated at hyperscale. Per Apache Fluss × Iceberg Part 1.
- Streamhouse formalized as the new 2026 architectural pattern. Apache Fluss positions the Streamhouse as the unified streaming + batch architecture — replaces the "stitch streaming and batch systems" pattern with a single substrate. Per Apache Fluss blog.
- Fluss vs Paimon framing: two engines for the same architecture. Alibaba Cloud published a head-to-head on Fluss vs Paimon — Fluss = hot tier (sub-second latency, state-bloat reduction for Flink), Paimon = warm/historical tier (ACID + minute-level + Iceberg-compatible snapshots). Per Alibaba Cloud — Apache Fluss vs Apache Paimon.
- Fraud-detection pipeline reference architecture. Apache Fluss published a complete fraud-detection-pipeline reference using the Streamhouse pattern — demonstrates the sub-second-decision use case where the architectural win is most visible. Per Apache Fluss — Fraud detection with Streamhouse.
- Paimon as the "streaming lakehouse" name in 2026 documentation. Ververica's Apache Paimon overview formalizes "streaming lakehouse" as the canonical name for the pattern — separate from "lakehouse" (batch-first) and "stream processing" (compute-only). Per Ververica — Apache Paimon: The Streaming Lakehouse.
Connections 10
Outbound 7
scoped_to2implements1depends_on2augments1solves1Inbound 3
enables3