[Project] NoKV — Go-native distributed KV: LSM + ValueLog + MVCC, Multi-Raft Regions, Redis-compatible gateway

Releases
1

Hi gophers! I’ve been building NoKV, a Go-native KV engine that combines:

  • Hybrid LSM + ValueLog (WAL → MemTable → SST, plus value separation)
  • MVCC transactions (snapshot isolation, conflict detection, TTL, iterators)
  • Multi-Raft regions via raftstore
  • A Redis protocol gateway (cmd/nokv-redis) so you can connect with Redis clients

Repo:

Quick start:

  • ./scripts/run_local_cluster.sh --config ./raft_config.example.json
  • go run ./cmd/nokv-redis --addr 127.0.0.1:6380 --raft-config raft_config.example.json
    or docker compose up --build

Feedback & contributions are welcome — especially around compaction/GC, MVCC design, and Redis compatibility/testing.

2

Hi, I am a senior golang developer and have 5 experiences of go.

I’ve been reviewing NoKV and really like the Go-native design, especially the hybrid LSM + ValueLog and MVCC approach. I have experience with Go, storage systems, and Raft-based architectures, and I’m particularly interested in compaction/GC and MVCC trade-offs. The snapshot isolation and conflict detection design caught my attention, and I’d enjoy contributing improvements or tests around those areas. I’ve also worked with Redis-compatible systems and can help test protocol compatibility and edge cases. I prefer long-term collaboration and thoughtful design discussions rather than one-off contributions. I’d be happy to start with a focused contribution and iterate from there.
I wish you are doing well. Thanks

3

Hi — thank you so much for the thoughtful review and the kind words!
I’m really glad the Go-native design, hybrid LSM + ValueLog, and MVCC approach resonated with you. Your background in storage systems + Raft (and Redis-compatible systems) sounds like an excellent fit for where NoKV is heading.

Quick update on where I’m focusing recently: I’m preparing a refactor of the ValueLog (vlog) architecture to explore more efficient read/write paths (especially around large-value handling and reducing hot-path pressure). While doing this, I’m also hitting a couple of practical gaps that would be great contribution entry points:

  1. Reverse iteration for the iterator

    • At the moment, the iterator doesn’t support backward iteration yet.
    • This impacts range scans and makes it harder to build certain MVCC/compaction validations cleanly.
    • If you’re interested, we can define the expected semantics (inclusive/exclusive bounds, snapshot visibility, performance expectations) and add correctness tests alongside the implementation.

  2. RESP / Redis gateway command coverage

    • The RESP layer currently supports only a limited set of commands.
    • Expanding command support + adding protocol/edge-case tests (TTL semantics, NX/XX behavior, pipelining, error cases, big payloads) would be super valuable.
    • Given your Redis-compatible experience, your input on a pragmatic compatibility test strategy would be very helpful.