Vector Databases & Indexing

A naive nearest-neighbor scan over 100M vectors is 400GB of math per query. Pinecone, Weaviate, Qdrant, and pgvector all give you 50ms recall@10 ≥ 0.95 on the same hardware — because of one idea: approximate nearest neighbor indexes (HNSW, IVF-PQ). This lesson is how Spotify finds your next song in 50ms and how Notion AI searches 100M+ pages without burning a datacenter.

Learning Objectives

After this lesson, you will be able to:

Understand why comparing every single vector one by one is too slow for real applications, and how approximate nearest neighbor (ANN) algorithms trade tiny accuracy losses for massive speed gains
Compare three indexing strategies — HNSW (graph-based for fast queries), IVF (cluster-based for large scale), and product quantization (compression-based for memory efficiency) — and know when to pick each one
Evaluate popular vector databases — Pinecone (managed), Weaviate (open-source with hybrid search), ChromaDB (prototyping), Qdrant (high-performance), pgvector (PostgreSQL extension) — and choose the right one
Design pre-filtering strategies that combine metadata constraints with vector search in a single pass to avoid wasting retrieval budget on out-of-scope documents

Prerequisites

Before You Start

Review

This lesson covers the infrastructure that powers every AI search feature you have ever used. It might feel technical, but the core ideas are surprisingly intuitive once you see the analogies. You have got this.

#The Needle in a Billion-Dimensional Haystack

Intuition

Build Your Intuition

Imagine you have a library with 10 million books. A visitor describes the book they want: "Something about a detective who solves mysteries using cooking." You need to find the most relevant books — fast.

The brute-force approach: read the summary of every single book and compare it to the visitor's description. With 10 million books, this takes hours. Clearly unacceptable.

A smarter approach: organize books into sections (mystery, cooking, science fiction), then subsections, then shelves. When a query comes in, quickly narrow down to the right section, scan that shelf, and return results in milliseconds.

Vector databases do exactly this for embedding vectors. They build clever index structures that let you find the most similar vectors among billions without comparing against every single one. The trade-off: you might occasionally miss the absolute best match, but you find very good matches thousands of times faster.

Why

Why This Matters

How Spotify stores 100 million song embeddings and finds your match in milliseconds — Spotify has over 100 million tracks, each represented as an embedding vector capturing its vibe; when you hit "Song Radio," a vector database finds the nearest songs among all 100 million in under 50 milliseconds using HNSW indexing — checking every song one by one would take minutes, not milliseconds
Why you cannot just use a normal database for AI search — a regular database can find "exact match" (show me all users named "Alex"), but it cannot find "similar meaning" (show me songs that feel like this one); vector databases are purpose-built to answer the question "what are the closest points in 1,536-dimensional space?" which is what makes semantic search possible
The technology behind "More Like This" everywhere you look — when Pinterest shows "similar pins," when Netflix says "because you watched," when Shazam identifies a song from a noisy clip — a vector database is finding nearest neighbors in embedding space at lightning speed; the HNSW algorithm you will learn in this lesson is the specific data structure powering most of these systems
Build this → Build a mini vector search: embed descriptions of 100 movies into vectors, store them in ChromaDB, then type a mood like "funny road trip adventure" and instantly find the 5 most similar movies — see how approximate nearest neighbor search makes this fast even as the collection grows

In the previous lesson, we learned how to convert text to vectors and measure similarity with cosine similarity. But computing cosine similarity between a query vector and every vector in your database is an O(n*d) operation — linear in both the number of vectors (n) and their dimensionality (d). For a million documents with 1536-dimensional embeddings, that is 1.5 billion floating-point operations per query. For a billion documents, it is 1.5 trillion operations. This is where approximate nearest neighbor (ANN) algorithms and vector databases become essential.

#How Vector Search Works: End to End

#Step 1: Documents to Embeddings

During ingestion, every document chunk is converted to a dense vector using an embedding model. These vectors — each a list of hundreds or thousands of floating-point numbers — are stored in the vector database alongside the original text and metadata.

#Step 2: Query Arrives

A user asks a question: "How do I reset my password?" This raw text needs to be compared against millions of stored document vectors to find the most relevant ones.

#Step 3: Embed the Query

The query is passed through the same embedding model used during ingestion. This produces a query vector in the same high-dimensional space as the document vectors. Now the question and all documents exist as points on the same map.

#Step 4: ANN Search (HNSW Graph Traversal)

Instead of comparing the query against every stored vector (brute force), the database uses an approximate nearest neighbor algorithm like HNSW. It starts at the top layer of a hierarchical graph, greedily navigates toward the query's neighborhood, and drops through layers for finer-grained search — examining only thousands of candidates out of millions.

#Step 5: Return Top-K Nearest Vectors

The search returns the K vectors closest to the query (typically K = 5 to 20). Each result includes a similarity score indicating how close the match is. These are the document chunks whose meaning is most similar to the query.

#Step 6: Retrieve Original Documents

The vector database looks up the original text and metadata associated with each returned vector. The chunk text, source document name, page number, and any other metadata are sent back to the RAG pipeline, which feeds them to the LLM as context for generating an answer.

#The Brute-Force Baseline

\text{Time}_{\text{brute}} = O(n \cdot d) \quad \text{where } n = \text{num vectors}, \; d = \text{dimensions}

At small scale (under 100K vectors), brute-force search is perfectly fine. Many RAG prototypes work this way. But production systems with millions to billions of vectors need something smarter.

Try it! Install ChromaDB (pip install chromadb) and add 10 short text snippets. Search with a question and see the results ranked by similarity. You just used a vector database. Now imagine doing this with 10 million documents — that is why the indexing algorithms below exist.

#HNSW: The Highway System for Vectors

Hierarchical Navigable Small World (HNSW) is the most popular indexing algorithm for vector search. It builds a multi-layered graph where each vector is a node, connected to its nearest neighbors.

What Do You Think?

If you have a billion vectors and need to find the 10 most similar, how many vectors does HNSW typically compare against?

Try it: Watch HNSW navigate the graph to find your answerInteractive

Loading visualization...

HNSW typically examines only a few thousand candidates to find near-optimal results among billions. Here is how it works:

#Layer 0: The Full Graph

Every vector is a node. Each node is connected to its M nearest neighbors (typically M=16-64). This is the bottom layer with maximum detail.

#Higher Layers: The Highway System

Random subsets of nodes are promoted to higher layers, forming a hierarchy. Layer 1 might have 10% of nodes. Layer 2 might have 1%. The top layer has very few nodes but provides long-range connections — like highways connecting distant cities.

To find nearest neighbors, start at the top layer. Greedily move to the closest node. Drop to the next layer. Greedily move again. Each layer provides finer granularity. By the time you reach Layer 0, you are in the right neighborhood and only need local refinement.

#Why It Works

The hierarchy creates "skip connections" across the vector space. Without them, you would need to traverse many local edges to get from one side to the other. With the highway layers, you can jump across the space in a few hops, then refine locally. This is what makes search logarithmic rather than linear.

\text{Time}_{\text{HNSW}} = O(\log n \cdot d) \quad \text{Recall@10} \approx 0.95{-}0.99

#HNSW Parameters

Parameter	What It Controls	Trade-off
M (connections per node)	Graph density	Higher M = better recall, more memory
ef_construction	Build-time search depth	Higher = better graph quality, slower build
ef_search	Query-time search depth	Higher = better recall, slower query

#IVF: The Clustering Approach

Inverted File Index (IVF) takes a different approach: cluster all vectors first, then search only within the most relevant clusters.

Build: Run K-means clustering to partition vectors into nlist clusters (typically 100-10,000).
Search: Compute distance from the query to each cluster centroid. Search only the nprobe closest clusters.

\text{Time}_{\text{IVF}} = O\left(n_{\text{list}} \cdot d + n_{\text{probe}} \cdot \frac{n}{n_{\text{list}}} \cdot d\right)

#IVF vs HNSW

Feature	HNSW	IVF
Build time	Slow (graph construction)	Moderate (K-means + assignment)
Query speed	Very fast	Fast (tunable via nprobe)
Memory	High (stores graph edges)	Lower (only centroids + lists)
Update (add new vectors)	Easy (insert into graph)	Hard (may need re-clustering)
Best for	Read-heavy, moderate size	Very large scale, batch workloads

#Product Quantization: Compressing Vectors

Both HNSW and IVF can be combined with Product Quantization (PQ) to dramatically reduce memory usage. PQ compresses each vector from, say, 1536 floats (6 KB) down to 48-192 bytes.

\mathbf{x} \approx [c_1(\mathbf{x}^{(1)}), c_2(\mathbf{x}^{(2)}), \ldots, c_M(\mathbf{x}^{(M)})]

#The Vector Database Landscape

Vector databases wrap these indexing algorithms in a full database system with APIs, persistence, filtering, and scaling.

#Pinecone (Managed)

Fully managed, serverless option available
Excellent for teams that want zero infrastructure management
Supports metadata filtering, namespaces, sparse-dense hybrid
Pricing by storage + read/write units

#Weaviate (Open Source + Cloud)

GraphQL and REST APIs
Built-in vectorization (can embed text automatically)
Supports hybrid search (BM25 + vector) natively
Multi-tenancy support for SaaS applications

#ChromaDB (Open Source)

Python-native, minimal setup
Perfect for prototyping and small-to-medium workloads
Runs in-memory or with SQLite persistence
Simple API: add, query, delete

#Qdrant (Open Source + Cloud)

Rust-based, very fast
Rich filtering with payload indexes
Supports quantization (scalar and product)
Good documentation and growing community

#pgvector (PostgreSQL Extension)

Vector search inside your existing PostgreSQL database
No separate infrastructure needed
Supports HNSW and IVF indexes
Best when you already use PostgreSQL and want simplicity

#FAISS (Library, not a database)

Meta's library for similarity search
Not a database — no persistence, no API, no filtering out of the box
The gold standard for raw search performance
Best as a building block inside your own system

#Try It Yourself

pythonplayground.py · Pyodide

import math
import random

# Simulate IVF (Inverted File) vector search
# Compare brute-force vs clustered search

def cosine_sim(a, b):
  dot = sum(x * y for x, y in zip(a, b))
  na = math.sqrt(sum(x ** 2 for x in a))
  nb = math.sqrt(sum(x ** 2 for x in b))
  return dot / (na * nb) if na and nb else 0

# Generate random 8-dim vectors (simplified)
def rand_vec(dim):
  return [random.random() - 0.5 for _ in range(dim)]

DIM = 8
N = 1000
K = 5
NUM_CLUSTERS = 10

# Create "database" of N vectors
vectors = [rand_vec(DIM) for _ in range(N)]

# Brute force: compare against ALL vectors
def brute_force(query, vecs, k):
  scored = [(i, cosine_sim(query, v)) for i, v in enumerate(vecs)]
  scored.sort(key=lambda x: x[1], reverse=True)
  return {"results": scored[:k], "comparisons": len(vecs)}

# IVF: assign vectors to clusters, search only nearby clusters
def build_ivf(vecs, num_clusters):
  centroids = vecs[:num_clusters]
  clusters = [[] for _ in range(num_clusters)]
  for i, v in enumerate(vecs):
      best_c = max(range(num_clusters), key=lambda ci: cosine_sim(v, centroids[ci]))
      clusters[best_c].append({"i": i, "vec": v})
  return {"centroids": centroids, "clusters": clusters}

def ivf_search(query, ivf, nprobe, k):
  comparisons = len(ivf["centroids"])
  cluster_dists = [(ci, cosine_sim(query, c)) for ci, c in enumerate(ivf["centroids"])]
  cluster_dists.sort(key=lambda x: x[1], reverse=True)
  probe_clusters = cluster_dists[:nprobe]

candidates = []
  for ci, _ in probe_clusters:
      for entry in ivf["clusters"][ci]:
          candidates.append((entry["i"], cosine_sim(query, entry["vec"])))
          comparisons += 1
  candidates.sort(key=lambda x: x[1], reverse=True)
  return {"results": candidates[:k], "comparisons": comparisons}

query = rand_vec(DIM)
ivf = build_ivf(vectors, NUM_CLUSTERS)

bf = brute_force(query, vectors, K)
ivf_result = ivf_search(query, ivf, 2, K)

print("Brute Force:")
print(f"  Comparisons: {bf['comparisons']}")
print(f"  Top sim: {bf['results'][0][1]:.4f}")

print(f"\nIVF (nprobe=2):")
print(f"  Comparisons: {ivf_result['comparisons']}")
print(f"  Top sim: {ivf_result['results'][0][1]:.4f}")
print(f"  Speedup: {bf['comparisons'] / ivf_result['comparisons']:.1f}x")

# Check recall: how many of brute-force top-K are in IVF results?
bf_ids = set(r[0] for r in bf["results"])
ivf_ids = set(r[0] for r in ivf_result["results"])
overlap = len(bf_ids & ivf_ids)
print(f"  Recall@{K}: {overlap}/{K}")

print("\nCHALLENGE: Try nprobe=5 and nprobe=10.")
print("How does recall improve? What about speed?")

Tests · Verify IVF uses fewer comparisons than brute force. Verify increasing nprobe improves recall. Verify nprobe=NUM_CLUSTERS gives perfect recall.

#Key Takeaways

Brute-force search is impractical at scale. Comparing a query vector against millions of stored vectors is too slow for production; approximate nearest neighbor (ANN) algorithms trade tiny accuracy losses for massive speed gains
HNSW is the most popular ANN index. Hierarchical Navigable Small World graphs enable sub-millisecond search over millions of vectors by building a multi-layer graph structure for efficient traversal
Product quantization compresses vectors for memory efficiency. By splitting vectors into subgroups and quantizing each separately, PQ dramatically reduces memory usage while maintaining good search quality
Choose your vector database based on scale and requirements. ChromaDB for prototyping, pgvector for PostgreSQL-based systems, Pinecone/Weaviate for managed scale, and FAISS/Qdrant for high-performance self-hosted deployments

#Picking a Vector DB in 2026: The Decision Matrix

The 2026 landscape stabilized: pgvector for <10M and Postgres-native shops, Qdrant or Weaviate for self-hosted with filtering, Pinecone serverless for pay-as-you-go, LanceDB for embedded/edge, and Vespa for late-interaction / ColPali workloads.

DB	Best for	Index	Filtering	Hybrid	Late-interaction (ColBERT/ColPali)	Pricing model
pgvector 0.7+	Postgres shops, <10M vec	HNSW + IVFFlat	SQL where	via tsvector	no	self-host
Qdrant 1.10+	self-hosted, rich filters	HNSW + scalar/int8	yes (payload index)	yes	yes (multi-vector)	self-host or cloud
Weaviate 1.25+	hybrid + ColBERT	HNSW	yes	native (alpha param)	yes (since 2024)	self-host or cloud
Pinecone Serverless	pay-as-you-go, no ops	proprietary	yes	sparse-dense built-in	partial	$0.03 / M reads
Vespa	Yahoo/Spotify-scale, late-interaction	HNSW + tensor	yes (YQL)	first-class	mature	self-host or cloud
LanceDB	embedded, edge, local	IVF-PQ + diskANN	yes	yes	partial	self-host (zero infra)
Milvus 2.4+	distributed, billion-scale	HNSW + IVF + DiskANN	yes	yes	partial	self-host or Zilliz Cloud
Turbopuffer	object-storage-backed, cheap cold	proprietary on S3	yes	partial	no	$0.04 / M reads (~70% cheaper)
ChromaDB	prototyping, single-process	HNSW	yes	partial	no	self-host, in-process

Rules of thumb that hold up in 2026:

< 1M vectors and Postgres in stack: just use pgvector. The latency and ops simplicity win.
Need ColPali / multi-vector retrieval: Vespa, Weaviate, or Qdrant 1.10+.
Going from zero queries to 10M queries this month: Pinecone Serverless (pay-as-you-go).
Cold-tier vectors (rarely queried, must be cheap to keep): Turbopuffer or LanceDB-on-S3.
Anything offline / on-device: LanceDB.

#Quick Check

Quick Check1 / 4

Why can't we use brute-force cosine similarity search at scale?

You now understand how vectors are stored and searched efficiently. But we skipped a crucial step: how do you turn large documents into the right-sized chunks for embedding? Next up: Chunking Strategies — the often-overlooked step that makes or breaks RAG quality.

Vector Databases & Indexing

Learning Objectives

After this lesson, you will be able to:

Understand why comparing every single vector one by one is too slow for real applications, and how approximate nearest neighbor (ANN) algorithms trade tiny accuracy losses for massive speed gains
Compare three indexing strategies — HNSW (graph-based for fast queries), IVF (cluster-based for large scale), and product quantization (compression-based for memory efficiency) — and know when to pick each one
Evaluate popular vector databases — Pinecone (managed), Weaviate (open-source with hybrid search), ChromaDB (prototyping), Qdrant (high-performance), pgvector (PostgreSQL extension) — and choose the right one
Design pre-filtering strategies that combine metadata constraints with vector search in a single pass to avoid wasting retrieval budget on out-of-scope documents

Prerequisites

Before You Start

Review

#The Needle in a Billion-Dimensional Haystack

Intuition

Build Your Intuition

The brute-force approach: read the summary of every single book and compare it to the visitor's description. With 10 million books, this takes hours. Clearly unacceptable.

Why

Why This Matters

How Spotify stores 100 million song embeddings and finds your match in milliseconds — Spotify has over 100 million tracks, each represented as an embedding vector capturing its vibe; when you hit "Song Radio," a vector database finds the nearest songs among all 100 million in under 50 milliseconds using HNSW indexing — checking every song one by one would take minutes, not milliseconds
Why you cannot just use a normal database for AI search — a regular database can find "exact match" (show me all users named "Alex"), but it cannot find "similar meaning" (show me songs that feel like this one); vector databases are purpose-built to answer the question "what are the closest points in 1,536-dimensional space?" which is what makes semantic search possible
The technology behind "More Like This" everywhere you look — when Pinterest shows "similar pins," when Netflix says "because you watched," when Shazam identifies a song from a noisy clip — a vector database is finding nearest neighbors in embedding space at lightning speed; the HNSW algorithm you will learn in this lesson is the specific data structure powering most of these systems
Build this → Build a mini vector search: embed descriptions of 100 movies into vectors, store them in ChromaDB, then type a mood like "funny road trip adventure" and instantly find the 5 most similar movies — see how approximate nearest neighbor search makes this fast even as the collection grows

#How Vector Search Works: End to End

#Step 1: Documents to Embeddings

#Step 2: Query Arrives

A user asks a question: "How do I reset my password?" This raw text needs to be compared against millions of stored document vectors to find the most relevant ones.

#Step 3: Embed the Query

#Step 4: ANN Search (HNSW Graph Traversal)

#Step 5: Return Top-K Nearest Vectors

#Step 6: Retrieve Original Documents

#The Brute-Force Baseline

\text{Time}_{\text{brute}} = O(n \cdot d) \quad \text{where } n = \text{num vectors}, \; d = \text{dimensions}

At small scale (under 100K vectors), brute-force search is perfectly fine. Many RAG prototypes work this way. But production systems with millions to billions of vectors need something smarter.

Try it! Install ChromaDB (pip install chromadb) and add 10 short text snippets. Search with a question and see the results ranked by similarity. You just used a vector database. Now imagine doing this with 10 million documents — that is why the indexing algorithms below exist.

#HNSW: The Highway System for Vectors

What Do You Think?

If you have a billion vectors and need to find the 10 most similar, how many vectors does HNSW typically compare against?

Try it: Watch HNSW navigate the graph to find your answerInteractive

Loading visualization...

HNSW typically examines only a few thousand candidates to find near-optimal results among billions. Here is how it works:

#Layer 0: The Full Graph

Every vector is a node. Each node is connected to its M nearest neighbors (typically M=16-64). This is the bottom layer with maximum detail.

#Higher Layers: The Highway System

#Why It Works

\text{Time}_{\text{HNSW}} = O(\log n \cdot d) \quad \text{Recall@10} \approx 0.95{-}0.99

#HNSW Parameters

Parameter	What It Controls	Trade-off
M (connections per node)	Graph density	Higher M = better recall, more memory
ef_construction	Build-time search depth	Higher = better graph quality, slower build
ef_search	Query-time search depth	Higher = better recall, slower query

#IVF: The Clustering Approach

Inverted File Index (IVF) takes a different approach: cluster all vectors first, then search only within the most relevant clusters.

Build: Run K-means clustering to partition vectors into nlist clusters (typically 100-10,000).
Search: Compute distance from the query to each cluster centroid. Search only the nprobe closest clusters.

\text{Time}_{\text{IVF}} = O\left(n_{\text{list}} \cdot d + n_{\text{probe}} \cdot \frac{n}{n_{\text{list}}} \cdot d\right)

#IVF vs HNSW

Feature	HNSW	IVF
Build time	Slow (graph construction)	Moderate (K-means + assignment)
Query speed	Very fast	Fast (tunable via nprobe)
Memory	High (stores graph edges)	Lower (only centroids + lists)
Update (add new vectors)	Easy (insert into graph)	Hard (may need re-clustering)
Best for	Read-heavy, moderate size	Very large scale, batch workloads

#Product Quantization: Compressing Vectors

Both HNSW and IVF can be combined with Product Quantization (PQ) to dramatically reduce memory usage. PQ compresses each vector from, say, 1536 floats (6 KB) down to 48-192 bytes.

\mathbf{x} \approx [c_1(\mathbf{x}^{(1)}), c_2(\mathbf{x}^{(2)}), \ldots, c_M(\mathbf{x}^{(M)})]

#The Vector Database Landscape

Vector databases wrap these indexing algorithms in a full database system with APIs, persistence, filtering, and scaling.

#Pinecone (Managed)

Fully managed, serverless option available
Excellent for teams that want zero infrastructure management
Supports metadata filtering, namespaces, sparse-dense hybrid
Pricing by storage + read/write units

#Weaviate (Open Source + Cloud)

GraphQL and REST APIs
Built-in vectorization (can embed text automatically)
Supports hybrid search (BM25 + vector) natively
Multi-tenancy support for SaaS applications

#ChromaDB (Open Source)

Python-native, minimal setup
Perfect for prototyping and small-to-medium workloads
Runs in-memory or with SQLite persistence
Simple API: add, query, delete

#Qdrant (Open Source + Cloud)

Rust-based, very fast
Rich filtering with payload indexes
Supports quantization (scalar and product)
Good documentation and growing community

#pgvector (PostgreSQL Extension)

Vector search inside your existing PostgreSQL database
No separate infrastructure needed
Supports HNSW and IVF indexes
Best when you already use PostgreSQL and want simplicity

#FAISS (Library, not a database)

Meta's library for similarity search
Not a database — no persistence, no API, no filtering out of the box
The gold standard for raw search performance
Best as a building block inside your own system

#Try It Yourself

pythonplayground.py · Pyodide

import math
import random

# Simulate IVF (Inverted File) vector search
# Compare brute-force vs clustered search

def cosine_sim(a, b):
  dot = sum(x * y for x, y in zip(a, b))
  na = math.sqrt(sum(x ** 2 for x in a))
  nb = math.sqrt(sum(x ** 2 for x in b))
  return dot / (na * nb) if na and nb else 0

# Generate random 8-dim vectors (simplified)
def rand_vec(dim):
  return [random.random() - 0.5 for _ in range(dim)]

DIM = 8
N = 1000
K = 5
NUM_CLUSTERS = 10

# Create "database" of N vectors
vectors = [rand_vec(DIM) for _ in range(N)]

query = rand_vec(DIM)
ivf = build_ivf(vectors, NUM_CLUSTERS)

bf = brute_force(query, vectors, K)
ivf_result = ivf_search(query, ivf, 2, K)

print("Brute Force:")
print(f"  Comparisons: {bf['comparisons']}")
print(f"  Top sim: {bf['results'][0][1]:.4f}")

print("\nCHALLENGE: Try nprobe=5 and nprobe=10.")
print("How does recall improve? What about speed?")

Tests · Verify IVF uses fewer comparisons than brute force. Verify increasing nprobe improves recall. Verify nprobe=NUM_CLUSTERS gives perfect recall.

#Key Takeaways

Brute-force search is impractical at scale. Comparing a query vector against millions of stored vectors is too slow for production; approximate nearest neighbor (ANN) algorithms trade tiny accuracy losses for massive speed gains
HNSW is the most popular ANN index. Hierarchical Navigable Small World graphs enable sub-millisecond search over millions of vectors by building a multi-layer graph structure for efficient traversal
Product quantization compresses vectors for memory efficiency. By splitting vectors into subgroups and quantizing each separately, PQ dramatically reduces memory usage while maintaining good search quality
Choose your vector database based on scale and requirements. ChromaDB for prototyping, pgvector for PostgreSQL-based systems, Pinecone/Weaviate for managed scale, and FAISS/Qdrant for high-performance self-hosted deployments

#Picking a Vector DB in 2026: The Decision Matrix

DB	Best for	Index	Filtering	Hybrid	Late-interaction (ColBERT/ColPali)	Pricing model
pgvector 0.7+	Postgres shops, <10M vec	HNSW + IVFFlat	SQL where	via tsvector	no	self-host
Qdrant 1.10+	self-hosted, rich filters	HNSW + scalar/int8	yes (payload index)	yes	yes (multi-vector)	self-host or cloud
Weaviate 1.25+	hybrid + ColBERT	HNSW	yes	native (alpha param)	yes (since 2024)	self-host or cloud
Pinecone Serverless	pay-as-you-go, no ops	proprietary	yes	sparse-dense built-in	partial	$0.03 / M reads
Vespa	Yahoo/Spotify-scale, late-interaction	HNSW + tensor	yes (YQL)	first-class	mature	self-host or cloud
LanceDB	embedded, edge, local	IVF-PQ + diskANN	yes	yes	partial	self-host (zero infra)
Milvus 2.4+	distributed, billion-scale	HNSW + IVF + DiskANN	yes	yes	partial	self-host or Zilliz Cloud
Turbopuffer	object-storage-backed, cheap cold	proprietary on S3	yes	partial	no	$0.04 / M reads (~70% cheaper)
ChromaDB	prototyping, single-process	HNSW	yes	partial	no	self-host, in-process

Rules of thumb that hold up in 2026:

< 1M vectors and Postgres in stack: just use pgvector. The latency and ops simplicity win.
Need ColPali / multi-vector retrieval: Vespa, Weaviate, or Qdrant 1.10+.
Going from zero queries to 10M queries this month: Pinecone Serverless (pay-as-you-go).
Cold-tier vectors (rarely queried, must be cheap to keep): Turbopuffer or LanceDB-on-S3.
Anything offline / on-device: LanceDB.

#Quick Check

Quick Check1 / 4

Why can't we use brute-force cosine similarity search at scale?

Vector Databases & Indexing

#The Needle in a Billion-Dimensional Haystack

#How Vector Search Works: End to End

#Step 1: Documents to Embeddings

#Step 2: Query Arrives

#Step 3: Embed the Query

#Step 4: ANN Search (HNSW Graph Traversal)

#Step 5: Return Top-K Nearest Vectors

#Step 6: Retrieve Original Documents

#The Brute-Force Baseline

#HNSW: The Highway System for Vectors

#Layer 0: The Full Graph

#Higher Layers: The Highway System

#Search: Top-Down Navigation

#Why It Works

#HNSW Parameters

#IVF: The Clustering Approach

#IVF vs HNSW

#Product Quantization: Compressing Vectors

#The Vector Database Landscape

#Pinecone (Managed)

#Weaviate (Open Source + Cloud)

#ChromaDB (Open Source)

#Qdrant (Open Source + Cloud)

#pgvector (PostgreSQL Extension)

#FAISS (Library, not a database)

#Try It Yourself

#Key Takeaways

#Picking a Vector DB in 2026: The Decision Matrix

#Quick Check

Deep Dive

Related Lessons

Your Reflection

Continue Learning

Discussion

Vector Databases & Indexing

#The Needle in a Billion-Dimensional Haystack

#How Vector Search Works: End to End

#Step 1: Documents to Embeddings

#Step 2: Query Arrives

#Step 3: Embed the Query

#Step 4: ANN Search (HNSW Graph Traversal)

#Step 5: Return Top-K Nearest Vectors

#Step 6: Retrieve Original Documents

#The Brute-Force Baseline

#HNSW: The Highway System for Vectors

#Layer 0: The Full Graph

#Higher Layers: The Highway System

#Search: Top-Down Navigation

#Why It Works

#HNSW Parameters

#IVF: The Clustering Approach

#IVF vs HNSW

#Product Quantization: Compressing Vectors

#The Vector Database Landscape

#Pinecone (Managed)

#Weaviate (Open Source + Cloud)

#ChromaDB (Open Source)

#Qdrant (Open Source + Cloud)

#pgvector (PostgreSQL Extension)

#FAISS (Library, not a database)

#Try It Yourself

#Key Takeaways

#Picking a Vector DB in 2026: The Decision Matrix

#Quick Check

Deep Dive

Related Lessons

Your Reflection

Continue Learning

Discussion