Skip to main content
Welcome back. Previously we covered how traditional databases perform exact keyword matching. That raises a big question: how do you search by meaning instead of exact words? In this lesson we’ll walk through that process and explain how vector databases enable semantic (meaning-based) search.

​
Overview

  • In a vector database, both your stored items and incoming queries are represented as vectors (numeric arrays called embeddings).
  • The system performs nearest-neighbor searches in a semantic vector space and returns items whose vectors are closest to the query vector.
  • This enables searching by meaning rather than by exact keyword matches.

​
How queries work in a vector database

When you submit a search phrase, it is converted into an embedding (a vector) using an embedding model. All documents or items in the database are stored as vectors produced by the same or a compatible model. The database compares the query vector to stored vectors and returns the most similar items. Example: Query text:
Query (embedded):
Think of the embedding space as a coordinate map where semantically similar concepts cluster close together. The database finds items whose vectors lie nearest the query vector using a nearest-neighbor search.

​
Example results and similarity scores

  • Laptop — similarity: 0.91 (very close): matches the query well.
  • Tablet — similarity: 0.89 (also relevant).
  • Chair — similarity: 0.29 (irrelevant).
Similarity scores come from applying a distance or similarity metric to vectors. Common metrics:
Choosing the right embedding model and similarity metric is crucial. Models trained on your domain (or fine-tuned) will place domain-specific concepts closer together and improve retrieval quality.
Similarity scores are model-dependent. Unexpected high or low scores may indicate an embedding/model mismatch or data-quality issue — inspect both embeddings and the model choice before tuning thresholds.

​
Semantic search vs. exact-match SQL

Here’s a side-by-side contrast to clarify the difference. Traditional database (exact-match SQL)
  • Operates on structured fields and exact values.
  • Best for transactional workloads, aggregates, joins, and ACID guarantees.
Example SQL:
Example result (exact match):
Vector database (semantic search)
  • Converts text into embeddings and searches a semantic vector space for nearest neighbors.
  • Returns items ranked by semantic similarity rather than exact keyword matches.
Conceptual flow:

​
When to use each system

​
Practical considerations

  • Indexing & performance: For large datasets, approximate nearest neighbor (ANN) indexes (HNSW, IVF, PQ, etc.) drastically improve query speed with modest accuracy trade-offs.
  • Scaling: Vector indexes and storage require different resource considerations compared to relational indexes (CPU/GPU for embedding generation, memory/SSD for ANN indexes).
  • Model choice: Off-the-shelf models often work well, but fine-tuning or using domain-specific embeddings improves relevance.
  • Evaluation: Validate retrieval using domain-specific relevance labels and metrics (e.g., recall@k, MRR).

​
Real-world example

Tools like Notion AI convert user queries into vectors and retrieve the most relevant notes by semantic similarity. This allows the system to return relevant content even when the user uses different words than the original notes — making search feel more like understanding than keyword matching.

​
Next steps / Further reading

Topics to explore next:
  • Embedding generation: comparing popular models and their trade-offs.
  • ANN indexes: HNSW, IVF, PQ and how they impact speed vs. accuracy.
  • Hybrid search: combining structured filtering with semantic ranking.
  • Evaluation: building labeled datasets and metrics for tuning retrieval.
Links and references Thanks — in the next lesson we’ll examine nearest-neighbor indexes and practical trade-offs between accuracy and latency for production semantic search systems.

Watch Video