Roadmap

[vjkxm]

I'm considering TiKV for my project and would like to use the Rust client, but it looks a bit neglected, especially compared to the C and Go clients. Is there a roadmap? Is it likely to remain maintained long term?

[eduralph]

A bit late, but we needed the answer to this question ourselves — posting what we found in case it's useful to others, and for the maintainers to adopt, adapt, or correct.

Is there a roadmap? Not an official one. But after comparing this crate against client-go at pinned revisions of both, the gap is well-defined enough to plan against. The measured distance, with client-go as the reference:

area	client-go	client-rust
transport	BatchCommands streaming + 4 conns/store	one unary RPC per op
routing	replica selector, follower/stale read, health/slow-score	leader-only
pessimistic locking	full LockCtx + fair locking	wait_timeout hardcoded
commit protocols	async commit + 1PC + fallbacks + pipelined DML	flags exist; no fallback paths
error taxonomy	~44 typed errors	one enum, mostly opaque KeyError
region-error handling / backoff	~22 kinds / ~18 tuned configs	~7 kinds / 4 presets
GC	service safepoints + GC controller	cluster safepoint only
metrics / config	~92 families / ~40 knobs	9 families / 6 knobs
testability	~132 probe fns exported for consumers	#[cfg(test)]-only mocks

A workable phase structure, dependencies first:

• Phase 0 — land what's already in flight: transaction: resolve orphaned locks whose primary was never written #544, transaction: clear prewrite locks on rollback of a failed pessimistic commit #547, request: replace try_join_all with JoinSet in plan handlers #549 are code-complete and CI-green today, awaiting review.
• Phase 1 — dependencies & toolchain: re-vendor kvproto (with a recorded revision), tonic 0.14 / prost 0.14, thiserror 2 / rand 0.9 and friends, edition 2024 plus a CI-tested MSRV policy, a CHANGELOG and release workflow.
• Phase 2 — low-risk, high-impact: typed errors (0.2: Improve error handling #238), pessimistic lock-wait control (Non-exclusive get_for_update #483), an async-commit safety fix, basic replica/stale read, raw checksum, read-path lock resolution (UCP: support resolving locks of specific keys #111 / Give the user more control over lock resolution #208 / Why do we not resolve locks for pessimistic transactions? #235), service GC safepoints (Support GC #180).
• Phase 3: complete async commit + 1PC (Support async commit and 1PC #287, Support large transaction #189), TTL manager (The beginning of heartbeats for pessimistic locks may be too late #312), backoff and region-error taxonomy (Fine-grained backoff #310 / Custom backoffs for raw requests #336 / Improve RetryableMultiRegion #337), region cache (Add region cache #299), config/TLS surface, observability, MemDB staging (Is there something like MemDB.Staging functionality of go client? #489), exported test probes (Test with fault injection and nemesis #284).
• Phase 4 — larger projects: BatchCommands transport (support BatchCommands interface for cleint-rust #442), store health + a replica selector, fair locking (Support fair/aggressive pessimistic locking (WakeUpModeForceLock) to lock-with-conflict instead of surfacing WriteConflict #546), pipelined DML, resource control.

On "will it remain maintained" — that's the maintainers' question to answer, but the merge history says more than it did when this was filed (#518–#548 landed Jan–Jul 2026), and we intend to keep contributing along the plan above. Along the way we've already filed #543 and #545 with fixes (#544, #547), plus #549.

Happy to turn any slice of this into trackable issues here if the maintainers want.