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 noevictionor a generousallkeys-lruceiling, 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.