Conformance

This page defines what a system must provide before it can call itself a lakestream — four properties, not a checklist of implementation details.

The four properties

1. Lakehouse-native storage — data lands in open formats, Parquet inside Iceberg or Delta Lake tables, on object storage, from the moment it's written — not behind a proprietary log format that a downstream job later converts.
2. Stream–table duality — one copy of that data serves both a tailing, offset-ordered stream read and a table scan; there's no separate copy or pipeline between the two. See stream–table duality.
3. Unified catalog — a stream and the table it materializes into are discoverable through one catalog surface, not two systems a consumer has to reconcile by hand.
4. Protocol-agnostic storage — the storage contract stands on its own, so Kafka, Pulsar, or another protocol can serve reads and writes against it without the contract itself changing.

What implementing means

These properties map onto the three API levels together, not any single one of them. Lakehouse-native storage and a unified catalog come from Level 2 — a StreamCatalog that resolves a stream's TableMaterializationPolicy to a registered TableCatalog, which a materializer later commits compacted data to. Stream–table duality depends on Levels 0 and 1 as much as Level 2: it only holds if the durable log that Log and LogStorage write is the same data a materializer later commits as a table, with no second write path. Protocol-agnostic storage is a property of the boundary itself — nothing at any level encodes Kafka or Pulsar semantics; a protocol implementation is a layer that sits on top and calls into this API.

How implementations line up

Ursa's architecture implements all three levels directly, end to end. Ursa for Kafka is the layer above it: a protocol implementation that speaks Kafka and calls into Ursa for storage, rather than reimplementing any of the four properties itself.