You might not need a vector database
Pinecone, Qdrant, Weaviate, excellent tools, genuinely. But a lot of teams reach for a whole vector database to do something a meaning-aware cache already does, with less to operate.
The vector database boom produced some genuinely great engineering, Qdrant, Weaviate, Milvus, Pinecone all deserve their reputations. But watch how teams actually use them for LLM apps and a pattern emerges: they're standing up a whole distributed database to answer one question over and over, 'have I seen something like this before?' That's not a database problem. That's a cache problem.
If your real goal is 'don't re-ask the model,' a cache is the smaller, sharper tool.
The difference is everything you don't have to assemble. With a vector database you're still writing the search logic, the reranking, the freshness rules, the trust checks, the eviction policy, the cache is the sum of all that, and you own the glue. Crowkis ships the glue: meaning-match, a reranker, confidence scoring, freshness, and eviction, in one binary that speaks a protocol your app already knows.
None of this is a knock on vector databases, if embeddings are your product, use one. But if embeddings are just how you avoid re-billing the model, a cache that happens to contain a world-class vector index is a lot less to run, and a lot faster to adopt.
The bottom line
Great tools, wrong shape for the job a lot of people are using them for. Before you operate a vector database to stop re-asking your model, try the cache that was built for exactly that, and drops in behind the client you already use.