Moon¶
The Redis-compatible in-memory data store, reimagined in Rust — 250+ commands, vector + full-text search, and cross-store ACID, with a thread-per-core core that reaches 2.29–2.40× Redis on pipelined GET.
2.40× Redis, GET p=64
1.78× Redis, SET p=64
15–17% less memory, ≥1 KB values
132/132 consistency tests
Measured on Linux, x86_64 — GCE c3-standard-8, --shards 1, c=50. Throughput vs Redis 7.0.15 at p=64; GET and SET only — every other command family runs 0.40–0.67× Redis at p≥8. Memory vs Redis 7.4.2/jemalloc, per-key RSS; Moon is worse below 256 B values and 1.7× worse when empty. Conditions and full matrix.
Moon is a Redis-compatible in-memory data store built from scratch in Rust. It implements 250+ commands with a thread-per-core shared-nothing architecture. Beyond Redis compatibility, Moon provides cross-store ACID transactions, HNSW vector + BM25 full-text search, a Cypher property graph, workspace partitioning, durable message queues, and bi-temporal MVCC.
Before quoting any performance number from this site
Every published figure must come from a Linux host per CLAUDE.md, and
every ratio depends on conditions that change it by more than the ratio
itself. Two in particular: the pipelined win is GET/SET only — on Linux,
INCR, LPUSH, SPOP and HSET all run 0.40–0.67× Redis at p≥8 — and the
memory win is large-value only: 15–17% less per key at ≥1 KB values, but
11–51% more at 32 B, and an empty moon server uses 1.7× the RSS of an
empty Redis (#821). All of
it is x86_64; on aarch64 at --shards 8 moon is 16% worse at 64 B. The
benchmarks page labels the host on every table; anything
marked macOS dev reference is a development record, not a result.
Note
Production-grade architecture, pre-1.0 maturity. Single-node Moon (v0.2.0) is recommended for production caching, AI workloads, and Redis-compatible OLTP. Multi-node clustering and multi-shard master PSYNC are alpha — see the production contract for the honest GA matrix. Wire protocol and on-disk format are LTS as of v0.2; CLI flags may still evolve until v1.0.
Highlights¶
-
250+ commands
Strings, hashes, lists, sets, sorted sets, streams, geo, HyperLogLog, pub/sub, transactions, Lua scripting, vector search, and graph.
-
Thread-per-core
Shared-nothing design with per-shard event loops, DashTable SIMD probing, and lock-free channels.
-
Dual runtime
Monoio (io_uring on Linux, kqueue on macOS) for peak performance. Tokio for portability.
-
Per-shard persistence
Forkless RDB snapshots and per-shard WAL with no global lock. AOF advantage grows with pipeline depth.
-
Cross-store transactions
TXN.BEGIN/COMMIT/ABORTfor atomic writes across KV, vector, and graph stores with undo-log rollback. -
Full-text + vector search
BM25 inverted index, HNSW + TurboQuant vectors, three-way hybrid fusion, and
FT.AGGREGATE. -
Workspaces & queues
Multi-tenant namespace isolation (WS) and durable at-least-once queues with dead-letter and triggers (MQ).
-
Drop-in compatible
Works with any Redis client — connect with
redis-cli, Jedis, ioredis, or redis-py out of the box.
Feature overview¶
Everything Moon ships today, grouped by area. 252 commands (per the COMMAND_META registry) across 25 groups — the full list lives in the command reference.
Core data store (Redis-compatible)¶
| Feature | What it does | Docs |
|---|---|---|
| Data structures | Strings, Hashes, Lists, Sets, Sorted Sets, and Streams — 100+ operations with RESP2/RESP3 semantics. | Commands |
| Geospatial | GEOADD, GEOSEARCH, GEORADIUS, GEODIST, GEOHASH, and more (8 ops). |
Commands |
| HyperLogLog | Probabilistic cardinality — PFADD, PFCOUNT, PFMERGE (3 ops). |
Commands |
| Keyspace & TTL | Expiry, SCAN, TYPE, key management, and keyspace notifications (15 ops). |
Commands |
| Pub/Sub | Channel and pattern-based messaging (5 ops). | Commands |
| Transactions | MULTI/EXEC/DISCARD/WATCH optimistic locking (5 ops). |
Transactions |
| Lua scripting | Sandboxed EVAL/EVALSHA with lazy sandbox init (5 ops). |
Commands |
| Connection & ACL | AUTH, HELLO, RESP2/3 negotiation, and 8 ACL commands. |
Security |
| Drop-in protocol | Works with redis-cli, Jedis, ioredis, redis-py, and any RESP client. |
Redis compatibility |
Search & AI¶
| Feature | What it does | Docs |
|---|---|---|
| Vector search | Native HNSW + TurboQuant (4-bit) index — COSINE/L2/IP, EF_RUNTIME tuning (11 FT.* ops). Light mode measured at 452 B/vector vs Redis Stack's 3,840 B on a macOS dev reference rig; not reproduced on Linux. |
Vector search |
| Full-text search | BM25 inverted index over TEXT/TAG/NUMERIC fields with typo tolerance. |
Full-text search |
| Hybrid fusion | Three-way BM25 + dense + sparse retrieval fused via Reciprocal Rank Fusion (RRF). | Full-text search |
| Aggregations | FT.AGGREGATE pipelines — GROUPBY, REDUCE, SORTBY, FILTER, LIMIT. |
Full-text search |
| Property graph | Cypher subset with vector-guided traversal — GRAPH.* (14 ops). |
Commands |
| Semantic cache | FT.CACHESEARCH single-RTT cache-or-search for LLM responses. |
SDK |
| Memory engine | Converged KV + vector + graph + ACID as a substrate for AI agent memory. | Memory engine |
| Python SDK | moondb typed client with LangChain and LlamaIndex vector-store adapters. |
SDK |
Durability & recovery¶
| Feature | What it does | Docs |
|---|---|---|
| Per-shard WAL/AOF | Lock-free per-shard append log — advantage grows with pipeline depth. | Persistence |
| RDB snapshots | Forkless point-in-time snapshots with no global stall. | Persistence |
| Point-in-time recovery | Replay the WAL to any timestamp (PITR). | PITR |
| Change data capture | Per-shard WAL streamed as Debezium-compatible JSON envelopes. | CDC |
| Cross-store ACID | TXN.BEGIN/COMMIT/ABORT atomic writes across KV, vector, and graph with undo-log rollback. |
Transactions |
Multi-tenancy & messaging¶
| Feature | What it does | Docs |
|---|---|---|
| Workspaces | Multi-tenant namespace isolation with per-workspace auth — WS (5 ops). |
Workspaces |
| Message queues | Durable at-least-once queues with dead-letter and debounced triggers — MQ (7 ops). |
Message queues |
| Temporal queries | Bi-temporal MVCC with AS_OF / VALID_AT time-travel across KV and graph. |
Temporal |
Performance & architecture¶
| Feature | What it does | Docs |
|---|---|---|
| Thread-per-core | Shared-nothing design with per-shard event loops and SO_REUSEPORT. | Architecture |
| Dual runtime | Monoio (io_uring on Linux, kqueue on macOS) for peak throughput; Tokio for portability. | Architecture |
| Compact SSO types | Inline keys (≤23 B) and values (≤12 B) — no heap allocation below the cutoff. Per-key memory on Linux x86_64: 15–17% less than Redis at ≥1 KB values, 11–51% more at 32 B; see benchmarks. | Architecture |
| Lock-free hot path | DashTable SIMD probing and flume channels — no global locks on writes. |
Architecture |
Operations & deployment¶
| Feature | What it does | Docs |
|---|---|---|
| Replication | PSYNC-based primary/replica streaming (5 ops). Multi-shard master PSYNC is alpha. |
Production contract |
| Clustering | Gossip + slot routing — CLUSTER (9 ops). Alpha; single-node is the recommended production target. |
Clustering |
| TLS | Encrypted client connections with cert rotation runbook. | TLS |
| Docker | Container images for local and production deployment. | Docker |
| Monitoring | INFO sections, slowlog, and metrics for observability. |
Monitoring |
| Security | ACL rules, Lua sandbox isolation, and a published threat model. | Security |
Key metrics¶
Linux only, each row with the conditions that produced it. Full report and the macOS development tables: benchmarks.
| Metric | Result | Conditions |
|---|---|---|
| Peak GET (v0.8.7) | 2.40× Redis | GCE c3-standard-8 x86_64, Redis 7.0.15, --shards 1, c=50, p=64 |
| Peak GET, ARM64 (v0.8.7) | 2.29× Redis | GCE t2a-standard-8 Neoverse-N1, same config |
| Peak SET (v0.8.7) | 1.78× x86 / 2.02× ARM | same runs |
| Every other command family | 0.40–0.67× Redis | INCR/LPUSH/SPOP/HSET at p≥8, both arches |
| Peak GET, absolute (v0.1.6) | 5.11M ops/sec (1.72×) | GCloud c3-standard-8 x86_64, p=64; Redis io-threads and payload size not recorded |
| Memory, ≥1 KB values | 15–17% less than Redis | GCE c3-standard-8 x86_64, --shards 1, Redis 7.4.2/jemalloc, per-key RSS (9.5% at 63K keys) |
| Memory, 256 B values | tie (±8%) | same run |
| Memory, 32 B values | 11–51% worse than Redis | same run |
| Empty-server RSS | 1.7× worse than Redis | same run — 12.6–12.9 MB vs 7.5–7.7 MB (#821) |
| Memory, 64 B values (aarch64) | 1.16× worse than Redis | GCE t2a-standard-8, --shards 8 vs Redis --io-threads 8 |
| CPU per operation | tie (10.55 vs 11.33 µs) | same run; moon 6× more stable run to run |
| Shard scaling (8 shards / 1 shard) | 1.42× / 2.14× / 3.79× | p=1 / p=8 / p=64, explicitly-keyed families |
| Vector search (384d) | 12.7K QPS | GCloud c3-standard-8 x86_64, HNSW + TurboQuant 8-bit, COSINE, 50K vectors, K=10 |
| Data correctness | 132/132 tests | all types, 1/4/12 shards |