kevy4.0

kevy 4.0

The data layer
for AI systems.

Redis-compatible, so you can swap it in. Faster on every operation. And it does what an AI system actually needs — vector search, full-text, secondary indexes, materialised views and a change feed — in the same engine, over the same keys.

Why you can replace RedisWhat else it doesRun it in your browser
$ cargo install kevy
$ kevy --port 6379

$ redis-cli -p 6379
> SET session:7f3a '{"user":"ada"}' EX 3600
OK
> IDX.QUERY idx:sem KNN "<vector>" LIMIT 10
1) "doc:4410"
2) "doc:9982"

Why you can replace Redis

Same protocol. More throughput.

Your client does not change — RESP2 and RESP3, 184 commands, the library you already use. One machine, 16 cores, loopback, small values, median of five runs.

GET
1.39×
SET
2.69×
INCR
1.77×
SADD
1.52×
HSET
1.42×
LPUSH
1.12×
ZADD
1.10×
kevy 4.0 Redis 8 margin under 15% — your workload decides, not the engine

LPUSH and ZADD are only 12% and 10% ahead. At that margin your value sizes and key distribution decide the winner. If lists or sorted sets are your hot path, speed is not the reason to switch. The full table, against valkey and Dragonfly too.

The things an AI system needs,
in the engine that already holds the data.

Not modules. Not a sidecar. Not a second copy of the truth drifting away from the first.

Vector

KNN over your keyspace

An HNSW index, declared once, kept current by the write path. You bring the embedding; kevy stores, indexes and searches it.

How Full text

BM25, and hybrid ranking

Full-text search over the same keys, and a hybrid query that fuses the text ranking with the vector ranking.

How Indexes

Look up by any field

Secondary indexes turn a filtered read back into a lookup. No query planner, no scan.

How Views

The answer, kept ready

Materialised views hold an aggregate current on the write path, so a read never recomputes it.

How Change feed

Tail every write

A resumable feed another process — or an agent — can follow. Nothing to poll.

How Anywhere

Server, binary, browser, device

The same engine and the same commands: a 16-core server, inside your binary, 151 KB in a browser tab, or a chip with no operating system.

How

Why an AI system needs a different data layer

An agent writes a document, embeds it, indexes it, caches it, and tells something else it changed. Today that is four systems — a cache, a vector database, a search index, a queue — holding the same facts and drifting apart. Every one of them is a place to forget a step.

kevy collapses them into one. Declare the index; write the key the way you already write it. The engine keeps the vector index, the text index, the secondary index and the view current on the write path, and the change feed tells anyone who is listening.

And it runs where the agent runs. In your service, inside the binary with no socket, in the browser tab as WebAssembly, or on the device at the edge of the network.

What are you building?

Each page says whether kevy fits, what it costs you, and exactly how — with commands you can paste.

AI

Agent memory & RAG

Vectors, full text, a change feed, and a TTL that expires a session for you.

How Serving

Reads without a database

Indexes and views, so a read stays a lookup instead of becoming a query.

How Cache

Sessions & rate limits

The rows that were never a database problem, off your database.

How Queues

Background jobs

Streams with consumer groups: a job survives the worker that was holding it.

How Realtime

Push to live clients

Pub/sub with pattern subscriptions — and across browser tabs, with no server.

How Embedded

Put it in the thing

Desktop app, browser, edge worker, microcontroller. No server, no socket.

How

Start

  1. As a server

    RESP on 6379. Your redis-cli and your client library do not know anything changed.

    cargo install kevy
kevy --port 6379

  2. In your Rust program

    No socket, no second process, no serialisation.

    kevy-embedded = "4.0"

let db = Db::open("data/")?;
db.set(b"k", b"v", None)?;

  3. In a browser tab

    151 KB. Persists to the browser's filesystem and survives a reload.

    import { open } from "@goliajp/kevy";

const db = await open({ persist: { name: "app" } });
db.set("cart:u1", json, { ttlMs: 3_600_000 });
What kevy will not do

It is not a cluster. Replication and failover exist; sharding data across machines does not, and will not. If one machine is not enough, kevy is the wrong answer. There is no AUTH and no TLS — run it on a private network or behind something that does those properly. And some commands differ from Redis: SCAN is not a cursor iterator, ZRANK is O(N), SPOP is not random. Every difference is written down, per command. And here is when not to use it at all.