🐘 pgvector — the library you already have
A Postgres extension: vectors as a column type, similarity as an operator, HNSW index included. Your data and your seats in ONE database, one backup, one access model — with SQL JOINs right next to semantic search.
✨ Where it shines
- one system: transactions, JOINs, backups you already run
- filters are just WHERE clauses — the L06 problem, solved by SQL
- fine to millions of vectors with HNSW
⚠️ Limits
- you operate Postgres (or pay RDS — AWS school!)
- extreme scale/latency needs eventually outgrow it
- vector features trail the specialists by months
🧭 Pick it when
- you HAVE Postgres and the corpus fits — the default answer
- compliance wants data in one audited place
☁️ Managed — Pinecone & friends (the rented hall)
Fully hosted vector search: you POST vectors, they handle indexes, scaling, filtered ANN, replication. The AWS build-vs-rent question (EC2 L08), answered 'rent'.
✨ Where it shines
- zero ops; scales past what you'd want to operate
- filtered ANN + hybrid done properly, by specialists
- predictable latency SLAs at big N
⚠️ Limits
- per-query/per-pod pricing adds up at volume
- your data leaves home (agreements matter)
- vendor coupling; migration = re-upload everything
🧭 Pick it when
- tens of millions of vectors + strict latency + no ops appetite
- the team is product-only and speed-to-market rules
🧪 Developer-first — Chroma · Qdrant · Weaviate · LanceDB
The lab benches: pip-install or one container, embedded or server mode, APIs built for AI apps. Each has a specialty — Qdrant (filters/perf, Rust), Weaviate (batteries included), Chroma (prototyping DX), LanceDB (columnar, local-first).
✨ Where it shines
- fastest start: notebook → prototype in minutes
- embedded mode = no server at all (SQLite energy)
- self-hostable at real scale (k8s school skills apply ☸️)
⚠️ Limits
- another system to run once past embedded mode
- maturity varies by feature — test YOUR filters + deletes
- easy start can hide the ops cliff at scale
🧭 Pick it when
- prototypes and mid-scale products
- self-hosting by choice, with the ops skills to back it
⚙️ Engines — FAISS · hnswlib · ScaNN
Not databases: LIBRARIES implementing lesson 04's indexes at maximum speed. No persistence, no filters, no replication — you build the database around the engine.
✨ Where it shines
- fastest raw ANN available; total control of index params
- research-grade: every algorithm, every knob
- embed inside your own service — no extra hop
⚠️ Limits
- everything else is DIY: storage, deletes, filters, HA
- GPU/memory tuning is on you
- easy to build a worse database than the ones for sale 😄
🧭 Pick it when
- you're building infrastructure or doing research
- extreme perf needs where a stock DB measured short
🔎 The old store learned new tricks — OpenSearch · Redis · Mongo · SQLite-vec
Your existing search/cache/document store grew a vector column. Often the pragmatic winner: one less system, hybrid search where the keywords already live.
✨ Where it shines
- reuse deployed infra, auth, backups, dashboards
- OpenSearch/Elastic: keyword+vector hybrid in one engine
- team already knows how to operate it
⚠️ Limits
- vector features are add-ons — depth varies a lot
- perf ceilings below the specialists
- two workloads now share one cluster's fate (noisy neighbors)
🧭 Pick it when
- it's already running and benchmarks say it fits
- hybrid search matters and your keywords live there
🧭 The boring pick order (from lesson 08)
1 have Postgres + corpus fits → pgvector · 2 prototype → embedded lab bench ·
3 big scale, no ops → managed · 4 big scale, ops appetite → Qdrant/Weaviate self-hosted ·
5 building an engine → FAISS · 6 under ~100k vectors → a loop is fine 😄 —
and whatever you pick, the embedder boundary (L05) keeps your vectors portable.