A vector database is a database built specifically to store embeddings and find the ones most similar to a new query vector, quickly, even across millions of stored vectors. A regular database is built to find exact or range matches on structured fields; a vector database is built to answer a fundamentally different question: "which of these is most similar to this?"
Learning Objectives
- Explain what a vector database does differently from a traditional database.
- Explain why exact nearest-neighbor search doesn't scale, and what approximate search trades off.
- Compare pgvector against a dedicated vector database, and know when each fits.
Storing and Searching Vectors
Documents
Embed Each One
Vector Database
vectors + metadata
Similarity Search
Each stored entry is typically the vector itself, plus metadata (the original text, a source ID, a timestamp) needed to actually use the result once it's found, the vector alone isn't useful without something pointing back to what it represents.
Why Exact Search Doesn't Scale
Finding the true closest vector to a query means comparing it against every single stored vector, an approach that gets impractically slow once a collection reaches millions of entries. Real vector databases instead use approximate nearest neighbor (ANN) algorithms, which find a very good match, almost certainly one of the truly closest, in a fraction of the time an exhaustive search would take.
The Accuracy/Speed Trade-off
Exact Search
always correct, slow
Approximate Search
fast, tunable accuracy
Good Enough Match
Most ANN algorithms expose a tunable knob trading recall (how often the true best match is actually found) against speed. In practice, a small chance of missing the single best match is an acceptable cost for search that stays fast as a collection grows into the millions.
pgvector vs a Dedicated Vector Database
| pgvector (Postgres extension) | Dedicated Vector Database | |
|---|---|---|
| What it is | An extension adding vector search to an existing Postgres database | A purpose-built system (e.g. Pinecone, Weaviate, Milvus) |
| Best fit | Already using Postgres, moderate scale, want one system for everything | Very large collections, need for the most advanced ANN tuning |
| Operational overhead | Low, one less system to run and maintain | Higher, a separate service to deploy and operate |
| Combining with existing data | Straightforward, vectors live alongside regular relational data | Requires syncing data across two separate systems |
Common Beginner Mistakes
- Choosing a dedicated vector database by default, when an already-running Postgres instance with pgvector would meet the actual scale and requirements.
- Forgetting to store metadata alongside the vector, a similarity match is useless if there's no way to trace it back to the original content.
- Assuming approximate search always finds the single best match, it's a probabilistic trade-off, tuned for speed at very large scale.
- Not re-indexing after bulk-updating a large number of vectors, stale indexes can degrade search quality or speed.
FAQ
Can a vector database also filter on regular fields, not just similarity?
Yes, most support combining similarity search with metadata filters, for example finding the most similar documents that also belong to a specific category or date range, this is often called hybrid or filtered search.
Does a vector database replace a regular database entirely?
Usually not. Most systems keep a regular database for structured, transactional data and use a vector database (or an extension like pgvector) specifically for the similarity-search workload, since the two are optimized for different kinds of queries.
Why not just compare every vector directly if the collection is small?
For a genuinely small collection, exact search is completely fine and simpler to reason about. ANN indexing becomes valuable specifically once the collection grows large enough that exhaustive comparison becomes slow.
Interview Questions
What does a vector database do differently from a traditional relational database?
It's optimized to find the stored vectors most similar to a query vector, a similarity search, rather than exact matches or range queries on structured fields, which is what traditional databases are built for.
Why do vector databases use approximate nearest neighbor search instead of exact search?
Exact search requires comparing a query against every stored vector, which becomes impractically slow at millions of entries. Approximate nearest neighbor algorithms trade a small, tunable chance of missing the true best match for search that stays fast as the collection scales.
When would you choose pgvector over a dedicated vector database?
When already running Postgres, at a moderate scale, and wanting to avoid the operational overhead of running and syncing a separate system, pgvector keeps vectors alongside existing relational data in one place.
Why is storing metadata alongside a vector important?
The vector itself is just coordinates, it has no inherent meaning on its own. Metadata (the original text, a source identifier) is what lets a similarity match actually be used once it's found.
Summary
A vector database stores embeddings alongside metadata and finds the most similar ones to a query using approximate nearest neighbor search, trading a small chance of missing the exact best match for speed at scale. pgvector fits well when already using Postgres at moderate scale; a dedicated vector database fits large, similarity-search-heavy workloads.
What's Next?
The next lesson covers chunking, how a large document gets split into smaller pieces before being embedded and stored.