Where streaming and historical data become one
Streambased is the unified store for real-time and batch data. Feed it change streams, events, and AI workloads; read it as a live stream, a historical table, or a key lookup, all from the engines you already run, with a single copy of the truth underneath.
Architecture
One store in the middle of everything
Sources flow in on the left. Streambased holds them as one continuously updated dataset. Every read pattern (streaming, batch, lookup, or a union of live and historical) comes out the right, served to the query engines you already run.
01 · Sources
Change Streams
Event Streams
AI Workloads
02 · Streambased
Unified real-time + batch store
Sub-second freshness · one copy of the truth
03 · Read patterns
Streaming Reads
Continuous, offset-ordered, replayable.
Batch Reads
Snapshot scans and time travel.
Lookup Join
Sub-millisecond key/value serving.
Union Read
Real-time and history in one query.
04 · Query engines
Why unified
Five systems, four seams, a standing engineering tax
The conventional real-time stack stitches together a broker, a processor, an online store, an offline store, and the pipelines that keep them in sync. Every seam is a place data quietly diverges. Streambased collapses the stack into one substrate.
Before · fragmented stack
5 systems · 4 sync boundaries · continuous engineering tax
1 substrate · 0 sync boundaries · single source of truth
The benefits, grounded in the architecture
Each capability is a direct consequence of one design decision. Together they collapse the fragmented real-time stack into a single coherent foundation.
One store, two speeds
Real-time and batch stop being separate systems. The same data is a live stream the moment it lands and a queryable table for as long as you keep it. One copy, one schema, one source of truth.
Architectural basis Unified log and table representation over open formats.
Union reads across time
A single query spans the last millisecond and years of history. No stitching a hot path to a cold path in application code, no reconciling two answers that quietly disagree.
Architectural basis Union read that merges fresh and historical data transparently.
Elastic, stateless compute
Compute stays lean and recovers in seconds because state lives in the store, not in your processing jobs. Scale the read path up and down without rebuilding state.
Architectural basis Store-resident state with fast snapshot recovery.
Columnar analytics, built in
Server-side projection, predicate pushdown, and partition pruning run on columnar streams, so analytical reads move a fraction of the bytes and the network stays quiet.
Architectural basis Columnar log format with a compound pruning stack.
Features and context, ready
Rows, columns, and vectors on one substrate. Online features, retrieval context, and analytics collapse into the same tables, accessed through the view each workload needs.
Architectural basis Multi-modal tables spanning structured and vector data.
Open formats, no lock-in
Readable by the engines you already run, in formats you already trust. The store is native and fast, the history is open, and nothing traps your data behind a proprietary wall.
Architectural basis Open lake formats end to end, queryable by any engine.
Real-time and batch, one platform
Stop stitching a hot path to a cold path. Give streaming and historical data one home, and query all of it from the engines you already run.