# Xline is a strongly consistent KV store built on the CURP consensus protocol

> Xline is a geo-distributed metadata store that speaks the etcd API but replaces Raft with CURP, and the whole point of the protocol is to remove one of the two network round trips a client waits for.

**xline-kv/Xline** — A geo-distributed KV store for metadata management

- Repository: https://github.com/xline-kv/Xline
- Website: https://xline.cloud
- Stars: 718 · Forks: 79
- Language: Rust
- License: Apache-2.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/xline-kv-xline

## The scope is deliberately narrow

Xline is meant to provide high-performance, strongly consistent metadata management for data centers in a wide-area network, and the scope section lists four things the project expects to cover. It is cloud-native and compatible with the Kubernetes ecosystem. It supports geo-distributed friendly deployment. It supports a rich set of key-value interfaces, fully compatible with etcd's API. And it ensures high performance and strong consistency in a wide-area network environment, using the CURP protocol as the underlying consensus protocol. That last item is the definition of the project, and the first one is the limit on it. Metadata means service discovery, configuration and coordination state, not rows of user data, and the etcd compatibility is a statement about the API surface rather than about storage. The project is a sandbox project of the Cloud Native Computing Foundation, and the readme invites questions and contributions through a Discord channel.

## Why two round trips is the problem to solve

The innovation section is the clearest technical argument in the repository, and it is worth following closely. Cross-datacenter network latency is the most important factor that impacts the performance of geo-distributed systems, especially when a consensus protocol is used. Raft is the usual answer, and it is stable and easy to implement, but it takes two round trips to complete a consensus request from a client's point of view. One round trip happens between the client and the leader server, and the leader takes another round trip to broadcast the message to the follower servers. In a geo-distributed environment a round trip is quite long, varying from tens of milliseconds to hundreds of milliseconds, so two of them is too long. The project adopts CURP to resolve that issue, with the main benefit described as reducing one round trip when contention is not too high. The readme claims Xline is the first product to use CURP, and points at the NSDI paper for the protocol itself and at a project blog post for a comparison against other protocols.

## The performance comparison is against etcd, in simulation

The comparison section describes a simulated multi-cluster environment with a deployment diagram and two workloads, one a single key case and the other a 100K key space case, with the results shown as a chart. The readme's own summary of the result is that it is easy to tell Xline has better performance than etcd in a geo-distributed multi-cluster environment. Two details are worth reading carefully. The word simulated matters, because the workload is driven by the simulation tooling rather than by a real fleet, and the repository carries a dedicated crates/simulation directory plus a set of patched madsim crates in the Cargo workspace that exist precisely to make that simulation deterministic. The patch section of the workspace manifest is explicit about why: a branch update the tonic version for madsim, and the intention is to switch to the original etcd-client crate when a new version is released. The second detail is the 100K key space case, since a single key case measures the consensus path and a large key space case measures how the store behaves when the data is spread out, and the two stress different parts of the system.

## The Rust workspace shows what the project actually contains

The Cargo workspace lists fifteen members and the names are a good map of the design. crates/curp is the consensus implementation, crates/curp-external-api is the protocol's external interface, and crates/curp-test-utils plus crates/test-macros hold the testing helpers. crates/engine is the storage and state machine layer, crates/xline is the server itself, and crates/xlineapi, crates/xlineutl and crates/xlinectl are the API definitions, the utility binary and the command line tool. crates/xline-client is the client SDK, with crates/xline-test-utils alongside it, and crates/benchmark is the benchmarking harness. The repository root is conventional for a serious Rust project: a rust-toolchain.toml pins the compiler, clippy.toml configures the linter, .typos.toml configures a spell checker, .pre-commit-config.yaml runs checks before a commit, .mergify.yml automates merging, and cliff.toml generates the changelog from commit messages. There is a Cross.toml for cross compilation, a ci/ directory, scripts/, fixtures/, doc/, a workspace-hack crate for dependency version unification, and an xline_server.conf at the root for the server configuration.

## Clients are first party, and that is a deliberate choice

Two client artefacts are documented separately from the server. The xline-client SDK lives in crates/xline-client and the xlinectl command line tool in crates/xlinectl, with a readme for each. The roadmap explains why there is a specific SDK at all when the store is etcd-compatible: although Xline is etcd-compatible, the project provides an Xline specific client SDK to users for better performance, and that SDK is currently only in Rust, with a plan to extend it to other languages. That is the interesting trade-off in the design. An etcd-compatible store can be driven by the etcd client libraries that already exist in Go, Python and Java, which is a large part of its appeal, but a client that speaks the native protocol can be faster than a translated one. The roadmap lists providing clients in other languages as not yet determined, so today the choice is between the generic etcd clients and a Rust SDK.

## The roadmap reads like a project plan rather than a wish list

The roadmap is organised by version range, which makes it unusually useful to read. The v0.1 to v0.2 range covers supporting all major etcd APIs, supporting a configuration file, and passing the validation tests, with a report linked that lists every supported etcd API and its validation result. The v0.3 to v0.5 range enables persistent storage, snapshots and cluster membership change, and implements a basic Kubernetes operator. The v0.6 to v0.8 range enables exporting metrics to monitoring and alerting systems, enables SSL and TLS certificates, and provides clients in other languages. The v1.0 range targets chaos engineering to validate the system's stability, integration with other CNCF components, and support for Karmada, a Kubernetes management system. The released versions follow that plan closely, with v0.6.0 from 2023-11-18, v0.6.1 from 2024-01-10 and v0.7.0 from 2024-08-26, and the last push to the repository was on 2026-10-09, which tells you the tree is being worked on without a release following it.

## Where this is the wrong choice

Three limits are worth naming. The first is that the payload of the idea is a protocol that has to behave correctly under partition, and the project's own v1.0 milestone is chaos engineering, which means the validation work is scheduled for the version where the project stops being pre-1.0. The second is that a CURP implementation in production is a different proposition from a CURP paper, and the readme's own claim is a first product to use the protocol rather than a proven track record, so an operator should weigh that carefully. The third is the metadata-only scope, which is a genuine limit when a workload needs to store and query application data. A final practical note is that the compatibility claim is the one to verify against your own client, since the validation report exists because the etcd API surface is large and the compatibility is per-API rather than blanket.

## Conclusion

Xline suits an operator running a metadata service across several regions who is hitting etcd's latency floor and needs an API-compatible way out, and it suits anyone who wants to read a consensus implementation that does not use Raft. It is the wrong tool if you need a general purpose database, since the scope is explicitly restricted to metadata management, and it is the wrong choice if you need a project with a long support record, because the newest tagged release is v0.7.0 from 2024-08-26 while the last push was on 2026-10-09. Before adopting it, read the validation report rather than the performance charts, since the compatibility with etcd APIs is the claim that matters operationally, and check the CURP paper before you reason about the protocol yourself. The last push was on 2026-10-09 and the current release is v0.7.0 from 2024-08-26.

## FAQ

### What is Xline and what consensus protocol does it use?

Xline is a Rust key-value store for high-performance, strongly consistent metadata management across data centers in a wide-area network. It uses the CURP protocol as its underlying consensus protocol, and it exposes a rich set of key-value interfaces that are fully compatible with etcd's API.

### Why does Xline use CURP instead of Raft?

Raft takes two round trips to complete a consensus request, one between the client and the leader and another as the leader broadcasts to the followers. In a geo-distributed environment a round trip can take tens to hundreds of milliseconds, so the project adopted CURP, whose main benefit is reducing one round trip when contention is not too high.

### Is Xline a CNCF project and how does it compare with etcd?

Xline is a sandbox project of the Cloud Native Computing Foundation. The README describes a comparison with etcd in a simulated multi-cluster environment under two workloads, a single key case and a 100K key space case, and states that Xline performs better in a geo-distributed multi-cluster environment. The simulation runs through a dedicated crates/simulation module with patched madsim dependencies for determinism.

## Sources

- [License: Apache-2.0](https://github.com/xline-kv/Xline/blob/master/LICENSE)
- [Project website](https://xline.cloud)
- [README](https://github.com/xline-kv/Xline/blob/master/README.md)
- [Releases](https://github.com/xline-kv/Xline/releases)
- [xline-kv/Xline on GitHub](https://github.com/xline-kv/Xline)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/xline-kv-xline