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?
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. The TABLE layer goes further: declare typed columns and indexes once (or compile a PG/MySQL schema file with kevy-sql) and a single table's read path — indexed WHERE, residual filters, ORDER BY, pagination — stays a lookup.
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, and with a RAM budget its dataset can be bigger than RAM (cold values spill to disk — RAM bounds keys, disk bounds data) — but past one machine's throughput you need something that shards, and that is not this.
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 | 481 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.
On the wire, yes — RESP2 and RESP3, 206 commands, and your client library will not notice. In behaviour, mostly, and the exceptions are the point. A cross-shard RENAME is not atomic — multi-key writes are atomic per shard, not globally. And a SCAN cursor is only valid on the server that issued it, the same per-node property Redis Cluster has. All 206 commands carry their real deviation and their real cost, read out of the implementation rather than copied from Redis's documentation.
Not any more. Turn on tiering and give the store a RAM budget: the coldest values spill to a disposable value log on disk and page back on access. Every command keeps its exact semantics on a cold key, and the append-only-log durability contract is untouched — RAM bounds how many keys you can hold, disk bounds how much data. The honest limits: it is off by default, v1 spills strings and hashes (lists, sets, sorted sets and streams stay hot), and values under 64 bytes never spill. The tiering guide states which numbers are measured and which are still targets pending the bench-box run.
Every write goes to an append-only log first, and the log replays on boot. With the default 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.
Yes — one primary, N replicas, with real failover: planned handover, crash election with epoch fencing, and an opt-in consistency ladder (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.
No, and there will not be. No AUTH, no ACLs, no TLS — permanently out of scope. Run kevy on a private network, or behind a proxy that does those things properly. A half-hearted auth layer is worse than an honest absence of one, because it invites people to trust it.
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.
