A vector database stores data as high-dimensional number arrays (embeddings) and finds similar items by comparing those numbers. Unlike regular databases that match exact values, vector databases find things by meaning.

Why AI needs them

When you search a regular database for “memory leak fix,” it only finds rows containing those exact words. A vector database finds results about “RAM overflow,” “garbage collection issues,” and “heap exhaustion” — because they mean similar things.

This is the foundation of RAG systems, AI search engines, and recommendation systems.

How it works

"The server is running out of memory"
    ↓ embedding model
[0.023, -0.041, 0.089, ...] (1536 numbers)
    ↓ stored in vector DB
    ↓ compared to query vectors using cosine similarity
    ↓ returns most similar documents

How vector search differs from traditional search

Traditional databases use exact matching or full-text search with inverted indexes. They find documents containing specific keywords. Vector databases use approximate nearest neighbor (ANN) algorithms to find items that are semantically close in embedding space.

The key algorithms used:

• HNSW (Hierarchical Navigable Small World) — graph-based, fast queries, higher memory usage
• IVF (Inverted File Index) — partition-based, good balance of speed and memory
• Product Quantization — compresses vectors for lower memory at slight accuracy cost

Most production vector databases use HNSW because it offers the best query latency for real-time applications.

A simple example

from qdrant_client import QdrantClient
from qdrant_client.models import VectorParams, Distance, PointStruct

client = QdrantClient(":memory:")

# Create a collection
client.create_collection(
    collection_name="docs",
    vectors_config=VectorParams(size=1536, distance=Distance.COSINE)
)

# Insert vectors
client.upsert(collection_name="docs", points=[
    PointStruct(id=1, vector=embedding_1, payload={"text": "memory leak fix"}),
    PointStruct(id=2, vector=embedding_2, payload={"text": "garbage collection tuning"}),
])

# Search by vector
results = client.query_points(
    collection_name="docs",
    query=query_vector,
    limit=5
)

Popular vector databases

Database	Type	Best for
Pinecone	Fully managed	Zero-ops production
Qdrant	Open source	Best performance
Weaviate	Open source	Hybrid search
Chroma	Open source	Prototyping
pgvector	Postgres extension	Already using Postgres

See our detailed comparison for benchmarks and pricing.

When to use one

• Building AI search or RAG
• Recommendation systems (“similar items”)
• Duplicate detection
• Image/audio similarity search

When NOT to use one

• Simple CRUD operations (use PostgreSQL or MongoDB)
• Exact lookups by ID
• Relational queries with JOINs
• Under 10K documents (full-text search is fine)

FAQ

Do I need a vector database if I only have a few hundred documents?

For small collections (under 10K documents), you can compute similarity in memory without a dedicated vector database. Libraries like NumPy or FAISS handle this well. A vector database becomes valuable when you need persistence, filtering, and scale beyond what fits in RAM.

Can I use PostgreSQL instead of a dedicated vector database?

Yes — pgvector adds vector search to PostgreSQL and works well for moderate workloads. It’s a great choice if you already run Postgres and want to avoid adding another service. Dedicated vector databases offer better performance at scale and more advanced indexing options.

How do I choose between Pinecone, Qdrant, and Chroma?

Use Pinecone if you want fully managed infrastructure with zero ops. Choose Qdrant for the best open-source performance and self-hosting flexibility. Pick Chroma for quick prototyping and local development — it runs in-process with no server needed.

Related: Vector Databases Compared · Embeddings Explained · What is RAG?