Skip to content

Moon vs Valkey — Deep Architectural Comparison

Reviewed: Moon v0.2.0 (~224K LOC Rust, traced from source) vs Valkey 9.1.0 (released 2026-05-19). Document date: 2026-05-25; version refreshed 2026-06-08; H-4 doc reconciliation 2026-07-10 (hash-field TTL corrected from "Moon does not implement" to "effective parity" — see §2).

0. Strategic Framing

These two projects are not the same kind of thing.

  • Valkey is the Linux-Foundation-stewarded continuation of Redis OSS — a C codebase forked from Redis 7.2 after the SSPL relicense (March 2024). Its commercial DNA is "drop-in Redis replacement, blessed by hyperscalers, governed in the open." Every change is constrained by preserving 30 years of Redis semantics and the C single-threaded-command-execution mental model.
  • Moon is a clean-room rewrite in Rust with a different bet: thread-per-core shared-nothing, in-process AI primitives (vector + BM25 + graph), and a converged data-platform surface. Wire-compatible, but the architectural premises diverge from the first byte. Single-node Moon is production-grade as of v0.2.0; multi-node clustering remains alpha — the README leads with that honest matrix.

The right mental model is Valkey = horizontal moat (ecosystem + governance), Moon = vertical moat (architecture + integrated AI surface). They compete on different axes, not feature parity.

1. Headline Comparison Table

Dimension Moon v0.2.0 Valkey 9.1.0 Strategic note
Language / age Rust edition 2024, MSRV 1.94, ~224K LOC, started 2025 C99, ~150K LOC pre-fork + ~30K added, lineage 2009 (Redis) Moon trades ecosystem maturity for memory safety + modern language.
License / governance Apache-2.0, single-project repo BSD-3-Clause, LF TSC, ~50 backers (AWS / GCP / Oracle / Alibaba / Tencent / Huawei…) Valkey is the safe-by-governance choice; Moon has no foundation, no co-vendor, no module ecosystem.
Threading model Thread-per-core, shared-nothing. Each Shard owns databases[16], pubsub_registry, vector_store directly — no Arc, no Mutex per src/shard/mod.rs. Cross-shard = lock-free SPSC (flume) + AtomicWaker response slots. Single main thread executes all commands. I/O threads (off by default; up to 9 used in published bench) parallelize parsing, response framing, epoll_wait. Comm model redesigned in 9.1 for +17 % throughput. Parallel read-execution on I/O threads (Issue #2022, 3.1M RPS prototype) is TSC-pending, not merged. Moon's model is structurally further along the scaling curve; Valkey is incrementally retrofitting concurrency onto a single-threaded core.
I/O driver Default monoio = io_uring on Linux / kqueue on macOS; tokio runtime alternative gated by feature. Same binary, dual codepath. SO_REUSEPORT per-shard listener. MOON_NO_URING=1 runtime kill-switch. epoll (Linux) / kqueue (macOS) only. No io_uring in any released or active PR (verified May 2026). No per-thread SO_REUSEPORT. RDMA exists as experimental compile flag. Moon owns "modern Linux I/O." Valkey's design philosophy is portability over peak-Linux.
In-memory data structure DashTable — custom segmented hash table = Dragonfly-style directory→segments→buckets + hashbrown-style Swiss-Table 16-way SIMD probing (src/storage/dashtable/). New open-addressing hashtable in 8.1 — 64-byte buckets, serverObject embeds key+value, replaces classic dict+dictEntry. Saves 20-30 B/KV vs Redis 7.2. Both made the same architectural realization (cache-line-aligned, embedded entries). Moon's is per-shard; Valkey's is global.
Per-key memory footprint CompactKey 23 B inline SSO; CompactValue 16 B SSO with inline TTL; HeapString for ≥24 B strings; listpack / intset / B+tree sorted sets — all custom. 27-35 % less RSS than Redis 8.6 at ≥1 KB values (Moon's own bench). Embstr threshold raised to 128 B in 9.1 (PR #1726/#2516) — 20 % less for short strings. Listpack, intset, quicklist, ziplist retained from Redis. Different optimizations: Moon wins on large values; Valkey 9.1 wins on tiny strings. Below 64 B Valkey may be tighter post-9.1 — needs head-to-head re-bench.
Persistence — snapshot Forkless compartmentalized snapshot (src/persistence/snapshot.rs). Serializes DashTable segments one at a time as cooperative tasks in the shard event loop; segment-level COW via per-snapshot overflow buffer for keys modified in not-yet-serialized segments. RDB v2 format (RRDSHARD magic, last_lsn, created_at_unix_ms for PITR). fork() + COW RDB child process. Memory spike during snapshot is the well-known production gotcha. RDB binary format. Clean architectural win for Moon. No fork = no 2× RSS spike, predictable tail latencies during snapshot, works in container / non-MMU environments.
Persistence — WAL/AOF Per-shard WAL v3 (src/persistence/wal_v3/) — RRDWAL magic, 64 B segment header, per-record LSN, checksummed records, lz4-compressed FPI, 16 MB segments, batched 1 ms flush + off-loop fsync agent. Multi-part AOF + RDB preamble + BGREWRITEAOF on monoio. 100 % crash-recovery validated. Three fsync policies. Single global AOF written by one background thread via POSIX write / fdatasync. Multi-part AOF (base + incremental, since Redis 7.0). RDB preamble. Three fsync policies. Moon's per-shard WAL eliminates the global write-serialization point — advantage grows with pipeline depth (2.75× over Redis at p=64 per Moon's bench).
Tiered storage Tiered NVMe disk-offload with cold-index, async write-back, read-through. Eviction spills under maxmemory instead of deleting. None in core; not on roadmap. (Redis Enterprise has Flash; Valkey OSS does not.) Moon-only feature; high differentiator for large-working-set / cost-sensitive workloads.
Replication PSYNC2 + per-shard shared replication backlog (SharedBacklog array; evaluate_psync_shared ANDs cover-check across shards). Async stream of WAL bytes. WAIT supported. No multi-master. PSYNC2, single replication backlog, diskless RDB streaming, WAIT. No multi-master in OSS (CRDT only in Redis Enterprise). Moon's per-shard backlog is the natural complement to per-shard WAL — but cross-shard PSYNC quorum logic is more complex. Both lack open-source active-active.
Clustering Redis Cluster compatible: 16384 slots, gossip (PING / PONG / MEET / FailoverAuthReq+Ack — magic 0x52656469 = "Redi"), 2048-byte slot bitmap per node, MOVED/ASK, election. Same 16384-slot model. 9.0 added atomic slot migration, multi-DB-in-cluster. 9.1 added CLUSTERSCAN. 2000-node target. Valkey's clustering is more battle-tested and has more recent feature work (atomic slot migration is genuinely valuable). Moon has feature parity at the protocol level but less operational mileage.
Command surface 250+ commands (252 entries in the phf static map in src/command/metadata.rs); ACL categories, flags (WRITE / READONLY / FAST / ADMIN / PUBSUB / …); FT. (vector + text), GRAPH. (Cypher subset, 14 cmds), TXN. (cross-store ACID), TEMPORAL., WS., MQ. added. ~240 Redis 7.2 commands + new ones (MSETEX, HGETDEL, HEXPIRE family, CLUSTERSCAN, DELIFEQ, CLIENT NO-TOUCH). FT., JSON., BF. live as separate modules*. Moon ships AI/transaction commands in-core. Valkey ships them as modules — a deliberate philosophy (small core, opt-in surface).
Vector search In-process HNSW + TurboQuant 1-8-bit quantization, MVCC, IVF, GPU scaffold (cudarc feature), hybrid graph+vector, hexagonal HNSW, 2-stage search pipeline. Bench: 12.7K QPS / 0.92 R@10 at 384d MiniLM, 8.2K insert/s. Auto-indexed on HSET. valkey-search 1.2.0 C++ module (March 2026). HNSW + FLAT, no quantization (FP32 only as of May 2026). Pre-filter vs inline-filter planner. Full-text + tag + numeric + vector hybrid in 1.2.0. "Single-digit ms latency, billions of vectors" — no published QPS/recall table. Moon's biggest single competitive advantage right now. Quantization (1-8 bit) is the lever that drops memory 4-32× — Valkey has none. Moon vs Redis published 12.7K vs 3.8K QPS at equal recall.
Full-text / BM25 Native in-core BM25 + FT.AGGREGATE (GROUPBY / REDUCE / APPLY), Levenshtein fuzzy via FST automata, TAG / NUMERIC field types, HIGHLIGHT / SUMMARIZE, three-way RRF hybrid fusion (BM25 + dense + sparse). In valkey-search 1.2.0 module: full-text added March 2026. Hybrid full-text + vector + tag + numeric. No reported maturity of relevance ranking yet. Roughly comparable surface at the syntax level; Moon's RRF + sparse fusion is more advanced than what valkey-search has documented publicly.
Graph database First-class property graph engine: 14 GRAPH.* commands, Cypher subset, CSR + SlotMap storage (src/graph/csr/), mmap'd CSR segments, SIMD-accelerated traversal, hybrid graph + vector queries, cross-shard traversal, bi-temporal VALID_AT. Bench: 23× FalkorDB insert, 2.4× Cypher QPS. None. No graph module, not on roadmap. FalkorDB remains a separate (Redis-module) project; not ported to Valkey. Moon-exclusive category. No Valkey path to closing this in the next 12 months.
Probabilistic DS HLL native (hll.rs, 30.5 KB). Bloom / cuckoo / count-min / top-k not in core (would need to be added). HLL native (12× AVX2 speedup in 8.1). Bloom / cuckoo / CMS / top-k via valkey-bloom 1.0 module. Valkey wider here. Easy add for Moon.
JSON Not a native type (HSET-based modeling). valkey-json 1.0 module — full JSONPath, available in valkey-bundle. Valkey wider. Moon gap.
Cross-store transactions TXN.BEGIN / COMMIT / ABORT — atomic writes across KV + vector + graph with undo-log rollback. MULTI / EXEC (KV-only, no cross-module ACID). Moon-only; meaningful for AI-pipeline use cases.
Multi-tenancy Workspaces (WS CREATE / WS AUTH) — transparent key prefixing + per-shard registries + token-scoped auth. Database-level ACLs (9.1 new) — restricts users to numbered DB indexes. Different shapes. Workspaces are a richer multi-tenant primitive; ACL-per-DB is simpler.
Message queue MQ CREATE / PUSH / POP / ACK — at-least-once, DLQ, debounced triggers, WAL-backed. Streams (XADD / XREAD / XGROUP), no native DLQ semantics. Different abstraction levels. Streams are lower-level; MQ is higher-level.
Bi-temporal TEMPORAL.SNAPSHOT_AT, TEMPORAL.INVALIDATE, FT.SEARCH AS_OF, GRAPH.QUERY VALID_AT. None. Moon-exclusive.
Modules Closed core (no module loader). All extension via Rust feature flags compiled in. Open module API v1 (C ABI, stable across versions). Rust SDK valkey-module crate. valkey-search / json / bloom / ldap as separate modules. Trade-off: Moon gets cohesion + safety (no foreign code in-process) and loses extensibility. Valkey gets ecosystem at the cost of C-FFI surface area.
Lua / scripting Lua 5.4 via mlua (vendored), lazy init. Lua moved to optional module in 9.1. Future custom-engine API; WASM mentioned. Both moving away from Lua-in-core.
Pub / Sub Per-shard PubSubRegistry, zero-copy Bytes fan-out, sharded SPSC scatter. Bench: 8.9× faster try_send, 1.48× Redis at multi-shard p=16. Standard PUBLISH / SUBSCRIBE + SHARDED PUB/SUB (cluster-aware). Moon's design is more cache-friendly per shard; Valkey's sharded variant is a recent retrofit.
Protocol RESP2 + RESP3 (zero-copy two-pass parser, parse_frame_zerocopy returns Frame::Null on any malformed input — no panic). RESP2 + RESP3 + RDMA experimental transport. Parity. Moon's parser defensiveness (fuzz-driven) is a hardening edge.
TLS rustls + aws-lc-rs, mTLS, works on both runtimes (tokio-rustls / monoio-rustls). OpenSSL-based, mTLS, 9.1 added auto cert reload + SAN URI mTLS. Valkey 9.1 has slightly nicer operator UX. Moon has memory-safe TLS stack.
Observability Built-in Prometheus exporter (metrics-exporter-prometheus), admin HTTP port, OTel feature flag reserved (otel cargo feature). Embedded React web console at /ui/ (Dashboard / Browser / Console / Vectors / Graph / Memory). INFO (with main-thread + I/O-thread CPU breakdown in 9.1), LATENCY, COMMANDLOG (8.1), slowlog, JSON log format (9.1), keyspace notifications. Valkey Admin GUI 1.0 released 2026-05-12 (separate tool). Server itself emits no OTel; OTel is client-side (GLIDE 2.0). Both have admin GUIs now. Moon's is embedded (one binary), Valkey's is a separate desktop / k8s tool. Prometheus is in Moon by default; in Valkey it requires oliver006/redis_exporter.
Memory safety 156 unsafe blocks with mandatory // SAFETY: audit (CI-enforced via scripts/audit-unsafe.sh). Unwrap ratchet. 7 fuzz targets (resp_parse, inline_parse, wal_v3_record, gossip_deser, acl_rule, …), 15 min/PR, 6 h nightly. Loom model tests. C memory model. Long history of CVE exposure (any C codebase of this age). Module ABI also exposes C unsafety surface. Architectural advantage Moon will own as long as the rewrite stays disciplined.
GPU acceleration cudarc feature flag, kernel scaffold under src/gpu/, vector-distance kernels planned. CPU + SIMD fallback mandatory. None. Moon-only direction; not yet shipping production kernels.
Published throughput 5.11M GET/s p=64, 3.50M SET/s p=64 (GCP c3-8, monoio, single server, Apr 2026). 2.20× Redis on ARM Neoverse-N1. 2.1M RPS (Valkey 9.1, 9 I/O threads, p=10, 512 B, single server). 1B+ RPS on 2000-node cluster (9.0 target). Single-server: Moon ~2.4× Valkey 9.1 (caveat: different harnesses). Cluster-scale: Valkey has demonstrated multi-node scale; Moon has not yet published cluster-scale numbers.
Production readiness Single-node production-grade as of v0.2.0; multi-node clustering alpha. No managed cloud offering. Moon Console + Rust/Python SDKs published. Production. AWS ElastiCache, Google Memorystore, Oracle OCI, Alibaba, Tencent, Huawei, DigitalOcean, Aiven, Heroku all GA. Bitnami + hyperspike + SAP Helm charts/operators. Valkey wins the production-readiness axis by a continent. This is Moon's biggest non-technical risk.
Client SDK story moondb Rust on crates.io, moondb Python on PyPI. Wire-compatible with any Redis client. All Redis clients work. Official valkey-glide (Rust core, Java / Python / Node / Go bindings, OTel built-in). Valkey has multi-language first-party clients with OTel; Moon relies on protocol compatibility.

2. Where Each Wins (Decisive)

Moon wins decisively on

  • Vector search performance + quantization — 12.7K QPS, 1-8 bit TurboQuant; Valkey has FP32 only, no public QPS.
  • Graph engine — Valkey has no graph at all.
  • Forkless persistence — no RSS spike, container-friendly.
  • Per-shard WAL — AOF throughput advantage grows with pipeline depth (2.75× at p=64).
  • Thread-per-core scaling architecture — Valkey is still moving execution onto I/O threads incrementally.
  • Memory safety — Rust + audited unsafe + fuzz / loom.
  • Single-binary AI surface — vector + BM25 + graph + transactions, no module loading dance.
  • Single-server peak throughput — ~2.4× Valkey 9.1 on comparable hardware (caveat: vendor benches).
  • Tiered NVMe disk offload.

Valkey wins decisively on

  • Ecosystem & governance — LF TSC, ~50 backers, every major cloud offers managed Valkey.
  • Production maturity — multi-year track record at AWS / GCP scale, multi-thousand-node clusters demonstrated.
  • Module ecosystem — JSON, Bloom, LDAP, Search ship as composable modules with stable C ABI + Rust SDK.
  • Atomic slot migration (9.0) — operational property Moon's cluster code does not yet match.
  • Cluster-scale benchmarks — 1B+ RPS, 2000 nodes demonstrated.
  • Multi-language official client — GLIDE 2.0 with server-side-aware semantics + OTel.
  • Operator / Helm tooling — Helm chart, operators, GUI, managed cloud everywhere.

Effective parity

  • Redis Cluster wire protocol (gossip, slots, MOVED / ASK).
  • RESP2 / RESP3 + RESP3 typed replies.
  • mTLS.
  • PSYNC2 replication, diskless full sync.
  • Listpack-class compact encodings.
  • 240-250 command surface.
  • Hash field expiration — Moon implements the full HEXPIRE/HPEXPIRE/HEXPIREAT/HPEXPIREAT/HTTL/HPTTL/HEXPIRETIME/HPEXPIRETIME/HPERSIST/HGETDEL/HGETEX family (src/command/hash/hash_write.rs, hash_read.rs), wired on both the read and write dispatch paths and WAL-replayed on recovery (src/persistence/replay.rs). A same-instance 3-way benchmark against Redis 8.0.2 / Valkey 9.1.0 (docs/perf/2026-05-27-hash-ttl-3way-bench.md) found Moon functionally correct but 4-10% slower than Valkey on HEXPIRE-family ops (HGETEX is at parity, 0.99x) — a known, tracked perf gap, not a missing feature.

3. Architectural Philosophy in One Line Each

Project One-line thesis
Valkey "Preserve Redis semantics; squeeze more throughput by parallelizing I/O off the main thread; extend via modules."
Moon "If you started over today, you'd use Rust, io_uring, thread-per-core, and put vector + graph + ACID transactions in the box."

The Valkey roadmap (atomic slot migration, parallel reads on I/O threads, JSON-format logs, RDMA, hash-field TTLs) tells you the team is incrementally modernizing a 15-year-old codebase. The Moon codebase tells you the team is building the dataplane they wish Redis had been.

Both are valid; they will likely coexist.

4. Risks for Moon (Project-Owner View)

  1. The missing managed offering and third-party validation are a moat for Valkey. Even with single-node v0.2.0 now production-grade, until Moon has a managed offering, a multi-year production reference, and an independent third-party benchmark validating the published numbers, Valkey wins every procurement conversation by default. This is the single highest-leverage item.
  2. No module API is starting to look like a strategic constraint, not a clean-architecture win. Valkey's ability to ship JSON, Bloom, LDAP, Search as modules — and to expose a Rust module SDK — means the community can extend Valkey faster than Moon's core team can extend Moon. Reconsider whether a sandboxed (WASM?) module surface is worth opening.
  3. Cluster operational features (atomic slot migration, CLUSTERSCAN, multi-DB-in-cluster) are real workload features Valkey shipped in 9.0 / 9.1 that Moon's cluster code does not yet match. These will surface in any serious operator evaluation. (Hash-field TTL is not one of these gaps — see §2 "Effective parity"; Moon has shipped the full HEXPIRE family since before this document's 2026-06-08 refresh, unrelated to cluster mode.)
  4. Valkey's vector module will add quantization. It's the obvious next step and they have the contributor base. Moon's current TQ moat shrinks every quarter — lean into agentic / hybrid / temporal differentiation that's harder to copy.
  5. Multi-language client story. GLIDE 2.0 is a real asset; Moon's two SDKs (Rust + Python) are insufficient for adoption at scale.
  6. Cluster-scale benchmark gap. Moon has not published >1-node scaling numbers comparable to Valkey's 1B-RPS / 2000-node demonstration. The shared-nothing architecture should scale better than Valkey's main-thread bottleneck — but until that's shown publicly, it's a claim, not a fact.

5. Recommendation

The competitive narrative writes itself: "Moon is what Redis would look like if rewritten today for AI workloads on modern Linux." Moon's design choices are individually defensible and collectively coherent. The competitive risk is non-technical: governance, ecosystem, and managed-service distribution — exactly the axes where Valkey is unassailable.

Two strategic plays look high-value:

  1. Double down on the AI-platform vertical (vector + graph + transactions + hybrid + temporal) where Valkey has no path to parity in 12 months.
  2. Cross the credibility chasm with (a) one independent third-party benchmark, (b) a documented cluster-scale run (≥16 nodes), and (c) a stable storage-format guarantee. The absence of a managed offering and independent validation is currently the biggest single drag on adoption.

6. Source References

Moon (this repo, traced)

  • src/shard/mod.rs — Shard struct, per-core ownership, "no Arc, no Mutex" comment.
  • src/storage/dashtable/mod.rs — Dragonfly + Swiss-Table architecture.
  • src/storage/db.rs — Database, CompactKey, CompactValue, HeapString, listpack/intset thresholds.
  • src/persistence/snapshot.rs — forkless segment-COW snapshot engine.
  • src/persistence/wal_v3/ — WAL v3 format, RRDWAL magic, per-record LSN, checksummed records.
  • src/persistence/aof.rs — multi-part AOF, fsync policies.
  • src/replication/master.rs — PSYNC2 with shared per-shard backlogs.
  • src/cluster/mod.rs, src/cluster/gossip.rs — Cluster bus, gossip, MOVED / ASK.
  • src/command/metadata.rs — PHF command table, flags, ACL categories.
  • src/vector/store.rs — per-shard VectorStore, HNSW + TurboQuant.
  • src/graph/mod.rs — graph engine (CSR, Cypher, hybrid, cross-shard).
  • README.md, BENCHMARK.md — published benchmark tables.

Valkey (external)