marekvs
Grow your dataset. Keep RAM costs down.
MareKVS is a distributed, Redis-compatible database that stores data on SSD. Your full dataset doesn’t need to fit in expensive RAM, helping you control infrastructure costs as it grows. Use JSON and Protobuf CRDTs for concurrent updates, plus distributed budgets that cannot overspend during a network partition.
$ redis-cli -p 6379
marekvs> SET greeting hello
OK
marekvs> SADD tags rust distributed redis
(integer) 3
marekvs> INCR visits
(integer) 1
# Writes replicate asynchronously.Structured data that survives concurrent writes
MareKVS stores JSON documents and Protobuf messages as fine-grained CRDT records. Updates to different fields merge instead of replacing an entire document. Escrow-based budgets protect quantities that must never exceed a fixed limit.
JSON document CRDTs
Use the RedisJSON command surface with one CRDT record per path. Concurrent edits to different fields survive, and concurrent array appends converge without interleaving each writer’s run.
Explore JSON commands →Protobuf field CRDTs
Register schemas, bind message types to key prefixes, and validate writes on the server. Concurrent updates to different message fields merge; repeated fields and maps use CRDT semantics.
Explore Protobuf values →Distributed budgets
Reserve and commit capacity from any node. Escrow accounting prevents overspending through partitions and crashes; unsafe reservations fail closed instead of exceeding the budget.
Explore budget commands →SSD-backed datasets
Keep datasets larger than RAM on SSD. Size memory for active reads, write buffers, and database operations without holding every value in process memory.
Redis client compatibility
Connect over RESP2 or RESP3 on port 6379. Use supported
string, hash, set, sorted-set, list, stream, pub/sub, HyperLogLog,
JSON, Protobuf, and budget commands.
Convergent replication
Any node serves any key. Hybrid logical clocks and data-type-specific CRDT merge rules reconcile concurrent writes as replicas exchange updates.
Review document changes before applying them
The experimental DIFF.* extension turns
structured document versions into suggestions you can review individually,
using the same Redis connection.
Compare versions
Find insertions, deletions, moves, text edits, formatting and attribute changes. Compare two versions or merge two edited branches against a shared base.
Decide together
Accept, reject or leave suggestions pending. Decisions replicate with reviewer attribution; conflicting selections return the changes to resolve.
Apply a reviewed selection
Create an immutable result snapshot with a retryable request token, then fork it into a branch when you are ready to keep editing.
Consistency guarantees
MareKVS accepts reads and writes during network partitions. Replicas are eventually consistent; clients on different nodes may read different values until updates converge.
| Guarantee | What it means |
|---|---|
| Read-your-writes | A connection always sees its own prior writes. |
| Monotonic reads | A connection's reads never go backward in time. |
| Convergence | Given no new writes, all replicas reach the same value. |
| No resurrection | A deleted key stays deleted; tombstones outlive repair. |
| Exact counters | Concurrent INCR/DECR across nodes are never lost. |
| Bounded staleness | Cross-node divergence heals within seconds (15 s worst case). |
Guarantees depend on the operating conditions described in the
documentation. Cross-node transactions, linearizable reads, and Redis Cluster
MOVED/ASK redirects are unsupported. See
Consistency.
Cluster architecture
Redis clients (redis-cli, any RESP driver)
│ :6379
┌─────────────────┴─────────────────┐
│ Kubernetes Service │
└──┬──────────────┬──────────────┬───┘
│ │ │
┌────┴───┐ ┌────┴───┐ ┌────┴───┐
│ pod 0 │ │ pod 1 │ │ pod 2 │
│ RESP │ │ RESP │ │ RESP │
│ engine │ │ engine │ │ engine │
│ ondaDB │ ⇄ │ ondaDB │ ⇄ │ ondaDB │ :7373 mesh
└────────┘ └────────┘ └────────┘
└──────── chitchat gossip ─────────┘ :7946/udpEach node runs a RESP frontend, command engine, ondaDB storage engine, replication engine, and gossip membership layer. Read the architecture →
Performance targets and measurements
The latency and throughput figures above are design targets. In the documented single-node benchmark, MareKVS reached 0.38–0.59× KeyDB’s throughput while persisting writes; KeyDB ran with persistence disabled. These results come from single runs on Docker for macOS. See the measurements and methodology.
Run a local node
docker run -d --name marekvs -p 6379:6379 \
-e MAREKVS_NODE_ID=0 -e MAREKVS_REPLICAS_N=1 \
ghcr.io/yannick/marekvs:latest
redis-cli -p 6379 ping # PONG- A Redis-compatible endpoint on
:6379 - Health + Prometheus metrics on
:9121 - Follow the guide to configure a three-node cluster
Build with MareKVS
Read the deployment guide and supported commands before connecting your application.