Crowkis vs pgvector: your database deserves better than your cache traffic
pgvector is a lovely extension for storing embeddings next to your data. Routing every LLM query through Postgres is how lovely things die.
pgvector made vector search approachable: it's right there in Postgres, next to your tables, with SQL you already know. For RAG over modest corpora it's a genuinely good answer. But a cache lookup happens on every single LLM request, and pointing that firehose at your primary database couples your AI traffic to the same connection pool, vacuum schedule, and failover story as your orders table.
Caches and databases want opposite things. A cache wants sub-millisecond reads, aggressive memory use, cheap misses, and the freedom to evict; a relational database wants durability ceremonies, MVCC, and careful locks. An IVFFlat scan plus a payload join plus connection acquisition is a fine query, it's just not a cache hit. And nothing in SQL refuses to serve an answer because its source has a bad trust history.
- 1your app · redis-py · ioredis · Lettuce
- 2crowkis
- 3claude code · agents
- 4services
- 5your LLM provider
Four doors in, one cache, and the model only sees genuinely new questions.
Crowkis is the purpose-built path: an in-process HNSW index over an LSM store engineered for exactly this access pattern, with the intelligence layered where SQL can't reach, intent classes, confidence gates, poisoning checks, tenant walls. Your Postgres keeps doing what it's great at, unbothered by ten thousand cache probes a minute.
The bottom line
The rule of thumb is old and still right: don't make your system of record absorb your traffic spikes. Cache in a cache. Keep pgvector for the data that belongs beside your data.