lakestream
Ursa

Ursa

The reference implementation of the Lakestream standard.

Ursa is the reference implementation of the Lakestream standard: a storage engine that turns object storage into the single copy of data a lakestream requires. Where concepts describes the pattern in the abstract and the specification defines its API, this section describes the code that implements both.

What Ursa is

Ursa writes every appended record first as a WAL object on object storage — no attached disks in the write path, and no replicated log service required beneath it, though one can sit there instead. A background compaction service folds a log's WAL objects into a compacted object, typically columnar Parquet, and — for internal tables — commits it directly into an Iceberg or Delta Lake table with no separate copy step. Offset assignment and the Stream Offset Index live in a dedicated Stream Catalog Service, backed by Oxia, rather than on whichever node happens to be a partition's leader; centralizing that assignment is what makes the architecture leaderless. See architecture for how Ursa's modules implement each of these pieces.

Its role in the ecosystem

Ursa is a Java library and a small set of services — not a protocol, and not a product on its own. Ursa for Kafka is the Kafka-compatible broker built on top of it: the storage layer under a diskless and leaderless Kafka cluster. The same engine also powers StreamNative's managed Ursa offering. Neither is the only possible implementation — any system that meets the specification can call itself a lakestream — but Ursa is the one this documentation, and the rest of this site's implementation-level content, describes in detail.

Research pedigree

The design behind Ursa — the WAL object and compacted object split, the leaderless catalog, zero-copy stream–table duality — is described in a VLDB 2025 paper that won the conference's Best Industry Paper award.

Maturity

Ursa is currently at version 5.0.0-M1 — a milestone release on the way to 5.0, not a final one. lakestream-api is where the public interface is stabilizing: it's the layer new integrations should target. ursa-storage-core, the internal engine underneath it, can still change shape without that affecting callers who stayed at the API level. Expect some movement in both as the project heads toward a 5.0 release. Published artifacts consumed downstream currently track the 4.1.x line instead — Ursa for Kafka pins io.streamnative:ursa-storage-ml at 4.1.3.2 — so the engine's development version and the published artifact version differ for now.

Where next