The streaming platform with no partitions to manage.
Whitewater is a clean-sheet streaming platform and distributed database. You create a feed and choose a business key — the riverbed handles placement, replication and durability underneath.
Six first-party SDKs, one exact contract
Java is not a privileged runtime on Whitewater. Every SDK implements the same Writer, Reader, Subscription, StateStore, Index, Pipe, supervised permanent consumer, and in-memory unit-test double — gated on one shared 22-scenario conformance suite.
Whitewater.Client
Zero external dependencies (System.Net.Http + System.Text.Json). Codec-bound Feed<K,V> and Store<K,V>, await foreach supervised ConsumeAsync, and Whitewater.Testing.FakeRiverbed.
github.com/osodevops/whitewater-go
Zero external dependencies. Generic Feed[K,V] and Store[K,V] facades, channel-based supervised consumer.Messages(ctx), WCL & typed commands, and the testkit fake riverbed.
dev.whitewater:whitewater-client
Built on standard java.net.http + Jackson. Typed Feed and StateStore codecs (JSON, Protobuf, Avro), feed.consumer("r").onRecord(...).run(), and dev.whitewater.testing.FakeRiverbed.
whitewater-client
Zero runtime dependencies using native fetch. Exact bigint 64-bit nanosecond record times, for await (const msg of feed.consumer("r")), and createFakeRiverbed unit-test double.
whitewater-client
Clean dataclass and JSON codecs, idiomatic for msg in feed.consumer("r"): supervised consumption, named-key StateStore lookups, and whitewater.testing.FakeRiverbed.
whitewater
Native async Rust client sharing the wire contract: typed feeds and stores, while let Some(msg) = consumer.next().await?, optional compression, and whitewater::testing::FakeTransport.
Six nouns. None of them is “partition”.
Everything an application needs to know fits in one line.
Immutable temporal history
A replayable, durable event log — no partition count, no replica assignment, no per-feed sizing exercise. Internal ranges split, merge and move beneath a stable identity.
Business data defines order
Ordering is defined per feed and business key — an order, a customer, a device. Physical routing stays internal; unrelated keys proceed independently.
Opaque progress tokens
Readers keep opaque cursors, not physical offsets. No topic/partition/offset tuples, no position arithmetic — pass the token back, get the next records.
A database and a streaming platform — from the outset
Not a broker with state bolted on, and not a database with a change feed attached.
Durable by default
RF3 baseline: three replicas, two-of-three durable data and commit evidence before a write succeeds. No min.insync to remember — safe refusal when durability can't be met.
Indexes & StateStores
Persisted replicated indexes make current state queryable beside the history. StateStores give durable server-side key state — no export-everything-to-another-database workflow.
Pipes & subscriptions
Managed streaming computation (Forward, Enrich, and rolling-window Pipes) with atomic effects, and capacity-aware continuous delivery with shared progress — without client co-partitioning plans.
One Rust node binary
No JVM, no GC pauses, low baseline memory, predictable tail latency. Control plane participation included — the standard three-node topology uses Raft-committed metadata.
Six languages, one contract
Rust, Python, Java, C#, Node.js/TypeScript and Go SDKs with the same Writer, Reader, Subscription, StateStore, Pipe and Cursor semantics — gated on one conformance suite.
Managed by Whitewater UI (Coming soon)
Built from Kafka Streamyard, Whitewater UI will manage Riverbeds, Domains, Feeds, StateStores and Subscriptions — and includes a visual Whitewater Stream Builder.
What you stop managing
The goal isn't a friendlier partition screen — it's removing partition management from the application contract entirely.
| The job | With Whitewater | With Apache Kafka |
|---|---|---|
| Create an event stream | Create a feed — no partition count | Choose partition count + replication factor |
| Route related records together | Choose a business key | Pick a partitioning strategy |
| Scale consumers | Readers & subscriptions, no assignments | Consumer groups assign partitions |
| Store read progress | Opaque cursors | Topic/partition/offset tuples |
| Grow capacity | Add nodes — ranges move internally | Repartition & rebalance planning |
| Query current state | Replicated indexes & state stores | External DB or Kafka Streams app |
| Set durability | RF3 quorum is the protocol baseline | acks/min.insync tuning per topic |
| Coordinate the cluster | Control plane built into every node | KRaft (modern) — still user-operated |
Whitewater is operational today and undergoing extensive testing over the next few months. Managed Kafka offerings can automate several of the responsibilities above — Whitewater removes them from the application contract itself.
Run a riverbed tonight
A supported riverbed always has at least three nodes. The standard development setup publishes on ports 7071–7073 — one compose file, nothing else to install.
Visual Riverbed management & Stream Builder are on the way.
Built from Kafka Streamyard, Whitewater UI will give you a complete desktop workspace to manage Whitewater Riverbeds and visually build Whitewater Streams.