Ranking, Storing, and Measuring Results
Choosing a Vector Database
3 min read
Not all vector stores are the same kind of tool
"Vector database" covers a surprisingly wide range of products, from fully-managed cloud services to a single-file local library. Vector Databases in the AI Tech Stack course covers the concept at a high level; this lesson goes one level deeper into how the options actually differ.
Purpose-built, managed or open source. Databases designed from the ground up around vector search:
| Database | Notes |
|---|---|
| Pinecone | Fully managed, proprietary — optimized for ease of use, latency varies with load |
| Weaviate | Open source, near real-time indexing via HNSW |
| Milvus | Open source, highly scalable, supports multiple index types (HNSW, IVF, and others) |
| Qdrant | Open source, built in Rust, strong focus on fast real-time updates |
Search engines with vector support. Mature, general-purpose search engines that added vector search alongside their original keyword search:
- Elasticsearch and AWS OpenSearch — both support vector k-nearest-neighbor search (often via Lucene's HNSW implementation), operating on a near-real-time refresh cycle rather than truly instant indexing.
Relational databases with vector extensions. Traditional SQL databases enhanced to store and query vectors alongside your existing structured data:
| Database | Vector extension |
|---|---|
| PostgreSQL | pgvector |
| MySQL | Vector functions (limited) |
| SQLite | sqlite-vss |
This route is attractive when vector search is one feature of a larger application that's already built on a relational database — you avoid standing up an entirely separate system.
In-memory / local libraries. Fast, but built for research and prototyping rather than large-scale persistence:
- FAISS — widely used for research and local indexing.
- Annoy — well suited to mostly-static datasets.
- ScaNN — built for very high-speed approximate search.
What actually differs between them
Two questions tend to matter most in practice:
- How fast does newly-written data become searchable? Some databases (Qdrant, Pinecone, Weaviate) are built around near-instant indexing; others (Elasticsearch/OpenSearch, most relational extensions) operate on a refresh interval, meaning a newly-indexed chunk might not be searchable for a second or more.
- Does it need to scale past what fits comfortably in memory, and does it need to run alongside data you already store elsewhere? A local library is fine for a prototype; a managed or purpose-built database is usually the right call once you're indexing millions of chunks in production; a relational extension is the right call when vector search is a feature bolted onto an existing structured database rather than the main event.
Key takeaway
Vector databases split roughly into four camps — purpose-built (managed or open source), general search engines with vector support bolted on, relational databases extended with a vector type, and in-memory libraries for prototyping — and the right choice depends less on raw features and more on how fast you need new data to become searchable and how it fits into the rest of your stack.
What's next?
Retrieval — however it's stored and searched — doesn't have to be the last word on ranking. The next lesson covers reranking: a second, more careful pass over whatever retrieval already found.