EmbedCache vs raw Redis as an embedding cache

A fair comparison of EmbedCache and the common DIY pattern of using Redis as a content-keyed store for embedding vectors.

At a glance

Dimension	EmbedCache	Redis used directly as a key-value cache for embeddings
What it is	A Rust library and REST service that bundles a local embedder (FastEmbed) with a SQLite cache.	Redis used as a generic KV store with vectors stored as serialized byte blobs under content-hash keys. You bring the embedder, the serialization, and the key derivation.
What you implement	Nothing — install the crate or run the binary.	Cache-key derivation, serialization (msgpack/JSON/protobuf), Redis client wiring, eviction policy, and the embedder integration. All on you.
Persistence model	SQLite file on local disk. Survives restart trivially. Can be rsynced to another host.	Depends on Redis config — AOF, RDB, or in-memory only. Persistence is opt-in and operationally non-trivial at scale.
Eviction See: Content-hash vs LRU note.	None by default. Content-hash keys are stable; entries live until you drop them.	LRU/LFU/TTL via Redis maxmemory-policy. Tuning is on you. Default policy on most Redis deploys evicts based on recency, which is wrong for embedding workloads.
Storage cost	SQLite on disk — cheap. A 1M-row cache at 1536-dim float32 is ~6GB on disk.	Redis in RAM — expensive. The same 6GB lives in memory unless you've enabled Redis on Flash or a similar tiered backend.
Embedder bundled?	Yes — FastEmbed, 22+ models.	No. Bring your own. Redis is a cache, not an embedder.
Operational shape	One process, one SQLite file.	Redis server + your embedder process + your wiring code. Three components to monitor.
Networked access	REST API on a port if you run the service binary. Or in-process via the crate.	Native Redis protocol over TCP. Multi-client friendly out of the box.
Best fit	You want the embedder and the cache as one thing, on one box, with one config file.	You already run Redis, you have multiple language clients hitting the cache, and you've thought hard about the eviction policy and persistence story.
When it's the wrong tool	You need horizontal scale across many embedder workers sharing one cache. EmbedCache's SQLite is local-first; Redis is the better choice for that topology.	You don't already run Redis and you're adding it just for this. The operational tax isn't justified by the savings on a single-node embedder.
License	GPL-3.0.	Redis OSS (BSD) or Redis Source Available depending on version.

When to pick which

Redis-as-cache is the classic DIY pattern: hash your text, dump the vector blob into a Redis key, set a TTL or don’t, move on. It works. It’s also more work than people remember when they propose it in a design doc.

Pick raw Redis if:

You already run Redis as part of your infrastructure. The marginal cost of using it for one more thing is low.
You have multiple services in multiple languages that all need to hit the same embedding cache. Redis is the obvious shared cache.
You’re sure about your eviction policy and your persistence story. (For embedding workloads, that means maxmemory-policy noeviction or a generous allkeys-lru ceiling, plus AOF if you can’t afford to lose the cache on a Redis restart.)
You want to embed with a model EmbedCache doesn’t bundle.

Pick EmbedCache if:

You want one thing to install. Not three.
You don’t want to debate eviction policy with anyone. SQLite never evicts unless you tell it to.
You’re running on a single node or a small fleet, and the multi-process cache-sharing problem isn’t actually yours.
You’re fine running a local FastEmbed model.

The architectural difference

Redis-as-cache is unbundled: you pick the embedder, you pick the serialization, you pick the eviction policy, you wire it all together. EmbedCache is bundled: the embedder, the cache backend, the serialization, and the eviction policy (none) are decided for you. Both are valid points on the unbundled-bundled axis. The unbundled approach is more flexible and more work. The bundled approach is less flexible and faster to ship.

If you are reading this comparison because you’re tired of maintaining the DIY version, that’s a strong signal for the bundled answer. If you’re reading it because you have a strong opinion about Redis persistence and you want full control, the bundled answer will feel constraining.

Both projects are honest about what they are. Pick the one whose constraints you can live with.