Vector databases — pick by load, not hype

A vector database does three things:

1. ANN — approximate nearest neighbour search (HNSW, IVF). Sub-millisecond k-NN over millions of vectors.
2. Storage — persist vectors + metadata, survive restarts.
3. Filters — combine vector similarity with metadata predicates ('tag = beta AND date > 2025').

Under ~100k vectors, you don't need a vector DB — sklearn or numpy is fine. Above 1M, you do. Between is the gray zone where in-memory FAISS or sqlite-vss often suffices.

Top picks in 2026:

- Qdrant — Rust, single binary, easy ops, great filters. My default for self-hosted.
- Weaviate — clean GraphQL/REST, good ergonomics, multi-tenant.
- pgvector — PostgreSQL extension. If you already have Postgres, start here.
- Pinecone — managed, fastest to ship; pay-as-you-go cost.
- LanceDB — embedded, file-based, no server.

Don't pick by Twitter hype. Pick by: existing infra, query latency target, filter complexity, ops budget.

Spin up qdrant via Docker. Insert vectors with payload (metadata). Search with optional filters. The API is the same shape across self-host or cloud.

Average retrieval latency is meaningless. Tail latency (p95, p99) is what your users feel.

Tune for p99 < 100ms on your cluster size. If you need more, options:
- Smaller embeddings (384 vs 1536 dim)
- Quantisation (PQ in Qdrant, scalar in pgvector)
- Pre-filtering by metadata before ANN
- Bigger HNSW M / efConstruction

Benchmark with realistic load patterns, not 1 query at a time.

Day 60 done.

- Vector DB = ANN + storage + filters
- Pick by load + ops, not Twitter
- 15-line Qdrant example
- Profile p99

Tomorrow (Day 61): top-k retrieval and the parameters that matter.