cloudparts

OxiaIncubating

A sharded metadata store and coordination service in Go, with ZooKeeper’s programming model (sessions, ephemeral keys, notifications, compare-and-swap) but capacity and throughput that grow by adding nodes; the recommended metadata store for new Apache Pulsar clusters.

CNCF · Sandbox
What it is
Coordination services
Type
Open source
Made by
The Oxia Authors (started at StreamNative); a CNCF Sandbox project
Foundation
Cloud Native Computing Foundation, sandbox, joined October 2025. Part of the Linux Foundation
License
Apache 2.0
Status
Incubating. A CNCF Sandbox project since 6 October 2025; releases are still numbered 0.x (0.16.11 in October 2026, 0.18 in release candidates).
Facts checked
24 October 2026
Website Source code

What it is

Oxia offers what ZooKeeper, etcd and Chubby offer, linearizable keys, sessions with ephemeral records that disappear when a client goes away, notifications of changes, versioned compare-and-swap writes and range scans, but it splits each namespace into shards. Each shard has its own leader, followers, write-ahead log and state stored in Pebble, an LSM key-value engine, and the client library hashes keys to shards, so different shards are written in parallel by different leaders. A partition key pins related keys to one shard. Because state lives in an LSM tree rather than in memory with periodic full snapshots, a cluster can hold hundreds of gigabytes of metadata, compared with the few gigabytes where ZooKeeper and etcd hit their limits.

Replication is deliberately not Raft. Within a shard the leader streams entries to followers and acknowledges a write once a quorum has persisted it; a separate coordinator, off the data path, assigns leaders, fences stale ones by advancing each shard’s term, and drives recovery after failures, the approach Apache BookKeeper uses. The coordinator keeps its small checkpoint in a Kubernetes ConfigMap, or in a built-in Raft group outside Kubernetes. Guarantees are per key and per shard: there is no linearizability or transaction across shards. Atomic sequence keys assign monotonic offsets as part of a Put, which StreamNative’s Kafka-compatible Ursa engine uses to number messages. Clients exist for Go, Java, Python, Node.js and Rust, and a Helm chart deploys it on Kubernetes.

Why teams pick it

  • Scales out: capacity and write throughput grow with the number of shards and nodes instead of being capped by one leader and the size of one node
  • Keeps ZooKeeper-style coordination primitives (sessions, ephemerals, notifications, conditional writes) that generic sharded key-value stores lack
  • No full-dataset snapshots, so large metadata sets don’t stall I/O
  • Protocol checked with a TLA+ model and Maelstrom (Jepsen-style) tests

Watch out for

  • No transactions or ordering across shards; related keys must share a partition key to be updated atomically
  • Young and pre-1.0, with nearly all maintainers at one company, StreamNative
  • Its listed adopters are Pulsar and StreamNative’s own Ursa; outside that ecosystem, tools and know-how are far scarcer than for ZooKeeper or etcd
  • Not a drop-in replacement: applications use Oxia’s own client APIs rather than the ZooKeeper or etcd protocols

Specs

Compare with alternatives →
Data model
Keys in sharded namespaces, with sessions, ephemeral records and sequence keys
Query language
Client APIs for Go, Java, Python, Node.js and Rust
Transactions
None across shards; versioned compare-and-swap per key
Consistency
Linearizable per key and per shard
How it scales
Hash-sharded namespaces, a leader per shard
Replication
Leader streams to followers, quorum ack; a coordinator assigns leaders and fences terms (not Raft)
Storage engine
Pebble (LSM) per shard, with a write-ahead log
Written in
Go
Ways to run it
Helm chart on Kubernetes, or outside Kubernetes with a built-in Raft coordinator

Alternatives

What all coordination services have in common →Compare side by side →
Apache ZooKeeperOpen sourceThe coordination service from Yahoo that a generation of Hadoop-era systems use for leader election, membership and configuration.etcdOpen sourceThe Raft-replicated key-value store that holds every Kubernetes cluster’s state, built for small, critical data that many machines must agree on.HashiCorp ConsulCommercialA service registry with health checks and a DNS interface, plus a service mesh that configures Envoy proxies for mTLS between services.

How it fits with other technologies

Go client: conditional writes and an ephemeral record tied to the client’s session · go

client, err := oxia.NewSyncClient("localhost:6648")

// create only if the key doesn't exist yet
insertedKey1, res1, err := client.Put(context.Background(), "my-key", []byte("value-1"), oxia.ExpectedRecordNotExists())

// compare-and-swap on the version we just wrote
insertedKey2, res2, err := client.Put(context.Background(), "my-key", []byte("value-2"), oxia.ExpectedVersionId(res1.VersionId))

// deleted automatically when this client closes or its session expires
insertedKey, res, err := client.Put(context.Background(), "my-key", []byte("my-value"), oxia.Ephemeral())

See it in a real stack

No architecture uses Oxia yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2021–2026

Apache Pulsar kept all its metadata and coordination in ZooKeeper. Like etcd and Consul, ZooKeeper is one replicated state machine: every node holds the whole dataset, every write goes through one leader, and periodic snapshots rewrite everything, which slows writes once the data passes about a gigabyte. Pulsar could reach about a million topics only with careful tuning, and had to keep consumer positions in BookKeeper ledgers because ZooKeeper couldn’t take the write rate. Matteo Merli, a co-creator of Pulsar and CTO of StreamNative, began Oxia in December 2021 and announced it as open source in April 2023, aiming at clusters with hundreds of millions of topics.

Pulsar added Oxia as a metadata store option and now recommends it for new production clusters, with live migration from ZooKeeper. StreamNative also built Ursa, its Kafka-compatible engine on object storage, on Oxia. Oxia was accepted into the CNCF Sandbox on 6 October 2025.

Why it’s built this way

Shard the keyspace
A single replicated log caps throughput at one leader and capacity at one machine; shards with independent leaders let both grow with the cluster.
Separate log replication from recovery, not Raft
Keeping the data path simple and fast, and putting elections and fencing in a coordinator, makes each part easier to optimise and to verify, as BookKeeper had shown.
LSM storage instead of in-memory state with snapshots
Pebble reads from consistent snapshots without dumping the whole dataset, so metadata can grow far beyond RAM.
Lean on Kubernetes
The coordinator’s tiny, rarely updated checkpoint fits in a ConfigMap, so Oxia needs no separate consensus service when running on Kubernetes.

Timeline

  1. 2021

    Matteo Merli makes the first commit in December

  2. 2023

    StreamNative announces Oxia as open source (April); 0.1.0 released

  3. 2025

    Accepted into the CNCF Sandbox on 6 October

  4. 2026

    0.16.11 in October; 0.18 release candidates

Sources9 · facts checked 24 October 2026

Improve this page on GitHub