Clients & libraries

Lakestream exposes two ways to consume it — the difference is whether your application already speaks a protocol like Kafka, or whether it wants direct access to the stream/table API underneath.

Speak a protocol

The zero-code-change path: point existing Kafka producers and consumers at an Ursa-backed broker and read and write as usual. Ursa for Kafka is a fork of Apache Kafka that runs designated topics diskless on Ursa storage — nothing about the client protocol changes, so existing applications need no new code to land on diskless storage. This isn't Kafka-only at the storage layer, either: Ursa also bridges Pulsar's ManagedLedger interface directly onto the same Log/LogCursor primitives, so Pulsar's ecosystem can run against the same storage without a second implementation underneath it. See Ursa's architecture for how that bridge fits together.

Embed the library

For a JVM service that wants first-class access to streams and the tables they materialize into — not just a Kafka-shaped view of them — link lakestream-api (the protocol-neutral interfaces) and ursa-storage-lakestream (the implementation) directly into your code. No broker sits in between; your service calls StreamCatalog, StreamWriter, and StreamReader the same way Ursa's own protocol adapters do. See Java for the modules, dependency coordinates, and a sketch of the API shape.

Language status

Java is first-class today: it's the language the reference implementation and its embeddable library ship in. Rust is a working port of the same library, useful for systems work outside the JVM. Kafka Connect support — sources and sinks that write to Ursa storage from the Connect runtime — is planned but not yet built.

Which one do I want