Choosing
Should you use kevy?
Sometimes not. This is the decision in the order you actually make it: is a key-value store even the right shape, where does the data have to live, and what are you giving up?
First — is a key-value store the right shape?
Use kevy when you know the key. A session id, a user id, a queue's name, a cache key. Reads are lookups, not questions. That covers more of an application than people expect — and secondary indexes and materialised views turn some of the questions into lookups too.
Do not use kevy when your reads are genuinely queries. Joins across five tables, ad-hoc analytics, a transaction spanning unrelated rows with real isolation — that is PostgreSQL, and it should stay PostgreSQL. We wrote down what each relational workload costs here, including the ones where the answer is do not.
Do not use kevy if one machine is not enough. There is no cluster mode and there will not be one. A single kevy does several million operations a second, which is more headroom than most products ever reach — but past it you need something that shards, and that is not this.
Second — where does the data have to live?
This is what picks the shape. The commands are identical in every row.
| Your situation | Use | Why |
|---|---|---|
| Several services share the data | Server | One process, RESP on a port. Your existing Redis client connects unchanged. |
| One program owns the data | Embedded | No socket, no second process, nothing to serialise. A function call, not a round trip. |
| The data belongs to the user's device | Browser | 151 KB of WebAssembly. Real TTLs and pub/sub, persisted to the browser's filesystem. Works offline. |
| Code runs at the edge, per request | Edge | Nothing to warm up, no connection to open. The store is in the isolate with your code. |
| A device with no OS and no heap | Bare metal | kevy-store is no_std: a fixed arena, no allocator. CI boots it on a Cortex-M on every push. |
You are not locked in. The embedded API and the wire protocol expose the same operations, so a program that outgrows its in-process store moves to a server by changing how it opens the database — not by rewriting how it uses it.
Third — what are you giving up?
Is it really a drop-in replacement for Redis?
SCAN is not a cursor iterator: one call sweeps the whole keyspace and returns cursor 0, so the usual SCAN loop finishes after a single round trip. ZRANK is O(N), because our sorted set has no rank index. SPOP and SRANDMEMBER are not random — they return the same members every time. A cross-shard RENAME is not atomic. All 184 commands carry their real deviation and their real cost, read out of the implementation rather than copied from Redis's documentation.What happens when the machine dies?
everysec fsync you lose at most a second of writes to a hard kill; set appendfsync = "always" and you lose nothing, at a cost in throughput. Snapshots exist only to bound how long the replay takes. The persistence guide has the numbers.Can I survive a machine failure?
WAIT, read-your-writes tokens, bounded staleness). What you do not get is data sharded across machines. Replicas are copies, not slices. The availability guide states exactly which writes survive a failover and which do not.Is there authentication?
What if I outgrow it, or just change my mind?
kevy-cli export writes your keyspace to a plain RESP file that any Redis-compatible server will import, and kevy-cli digest proves the copy is faithful before you throw anything away. The migration guide covers moving out as carefully as moving in.Open the playground. It is a real kevy engine compiled to WebAssembly, running in your tab — write keys, watch TTLs expire, look at the append-only log sitting on your own disk. Nothing is pre-recorded, and no server is involved.