At a glance
| Traditional (relational/document) database | Vector database / vector index | |
|---|---|---|
| Question it answers | "Which rows match these conditions?" | "Which items are most similar to this?" |
| Data | Structured fields: numbers, text, dates, IDs | Embedding vectors plus metadata |
| Matching | Exact or range (WHERE price < 20), keyword | Nearest neighbours by distance/similarity |
| Result | Precise: a row either matches or not | Ranked: closest k, with scores |
| Strengths | Transactions, integrity, joins, reporting | Semantic search, recommendations, RAG retrieval |
| Weak at | Finding by meaning | Exact lookups, joins, strict consistency (varies by product) |
| Index | B-tree, hash, inverted index | ANN indexes such as HNSW or IVF |
Product lines are blurring: several relational and search databases now support vector columns and similarity queries, and many vector databases support metadata filters.
What is each?
A traditional database stores structured records and answers precise queries with guarantees such as transactions and integrity constraints. Think PostgreSQL, MySQL, SQLite, MongoDB. Text search engines add keyword relevance (words, stemming, ranking).
A vector database stores What are Embeddings in AI? and finds the nearest ones to a query vector, usually via approximate indexes so it stays fast at scale.
Key differences
Exact vs fuzzy. If you need the order with ID 10492, a traditional database is perfect and a vector search is the wrong tool. If a user types "something warm for a rainy hike", only similarity over embeddings will connect that to "waterproof insulated jacket".
Correctness model. A SQL query returns exactly the matching rows. ANN vector search returns approximately the closest items; you tune the speed/recall trade-off.
What gets compared. SQL compares values you defined (columns). Vector search compares learned representations whose quality depends on the embedding model and on how content was chunked.
Operations. Traditional databases offer decades of tooling for backup, migration, access control and transactions. Newer vector systems vary in maturity; check the features you require.
Hybrid is common. Real search often combines keyword matching (for exact terms like SKU codes), vector similarity (for meaning), and metadata filters (for permissions and dates).
When to choose which
- Records, transactions, reporting, exact lookup → traditional database.
- Semantic search or RAG over a small corpus (thousands to low hundreds of thousands of chunks) → start with what you have: an in-memory array, SQLite or PostgreSQL with a vector extension.
- Large-scale, low-latency, frequently updated semantic search → a dedicated vector database or a search engine with strong vector support is worth evaluating.
- Need both → keep the source of truth in your traditional database and store embeddings alongside it (same database, or a synchronised index).
Example
An online store keeps products, stock and orders in PostgreSQL. To add "search by description", it adds an embedding column (via an extension) for each product, and a query that filters in_stock = true and price < 100 first, then orders by vector similarity to the query. One database, both kinds of question. If the catalogue later grows to hundreds of millions of items with demanding latency needs, a specialised service might make sense — a decision to make with measurements, not in advance.
Common mistakes
- Adding a vector database for data that a plain query answers.
- Replacing keyword search entirely, then losing exact-match behaviour for codes and names.
- Treating similarity scores as probabilities or truth.
- Duplicating data without a sync strategy, so the vector index drifts from the source of truth.
- Not measuring retrieval quality (How to Evaluate AI Systems and Outputs).