13 min

The Vector DB Landscape

Choosing Your Storage Layer

The Landscape at a Glance

The vector database market has exploded. Choosing the right one depends on your scale, infrastructure, and use case. Here's the decision tree:

Loading diagram...

Database Profiles

pgvector (PostgreSQL Extension)

What it is: A PostgreSQL extension that adds vector column types, indexing (HNSW + IVF), and distance operators.

Strengths:

Zero additional infrastructure — just add the extension

ACID transactions — vectors and metadata are always consistent

SQL — use familiar queries, joins, CTEs with vector search

Free and open source

Great for < 5M vectors with moderate query load

Limitations:

Single-node — no horizontal scaling

Index builds lock the table (can use CONCURRENTLY)

No built-in replication of vector indexes

Slower than purpose-built vector DBs at scale

Best for: Teams already on PostgreSQL who need vector search without adding infrastructure. The default choice for most startups.

Pinecone

What it is: Fully managed, serverless vector database. No infrastructure to manage.

Strengths:

Zero ops — no clusters, no tuning, no index management

Serverless pricing (pay per query + storage)

Excellent filtering with integrated metadata indexes

Namespace isolation for multi-tenancy

SOC 2 compliant

Limitations:

Proprietary — vendor lock-in risk

No self-hosted option

Can be expensive at scale ($0.08/1K queries + storage)

Limited query flexibility compared to SQL

Best for: Teams that want vector search without managing infrastructure and are OK with a managed service.

Qdrant

What it is: Open-source vector database written in Rust. Available self-hosted or managed (Qdrant Cloud).

Strengths:

Excellent performance — Rust-based, consistently top benchmarks

Rich filtering with payload indexes

Quantization support (scalar + product) for memory savings

Snapshot and replication support

gRPC and REST APIs

Limitations:

Smaller ecosystem than Pinecone/Weaviate

Managed cloud is newer, fewer regions

Clustering setup requires more configuration

Best for: Teams that want high performance with the option to self-host. Great for latency-sensitive applications.

Weaviate

What it is: Open-source vector database with built-in vectorization modules.

Strengths:

Built-in embedding — can vectorize text at insert/query time

GraphQL-like query language

Hybrid search (vector + BM25) built in

Multi-modal support (text, image, video)

Active community and good docs

Limitations:

Java-based — higher memory overhead

Built-in vectorization adds complexity and latency

Can be over-engineered for simple use cases

Best for: Teams that want an all-in-one solution including vectorization, especially for multi-modal data.

Chroma

What it is: Lightweight, open-source embedding database focused on developer experience.

Strengths:

Simplest API — get started in 5 lines of Python

In-process mode (no server needed for development)

Good for prototyping and small-scale production

Built-in support for document storage

Limitations:

Not designed for large-scale production (> 1M vectors)

Limited filtering capabilities

Single-node only

Python-centric (limited client support)

Best for: Prototyping and small-scale applications. Often the first vector DB developers try.

Milvus / Zilliz

What it is: Open-source vector database designed for billion-scale. Zilliz is the managed cloud version.

Strengths:

Designed for massive scale — billions of vectors

Multiple index types (HNSW, IVF, DiskANN, GPU indexes)

Distributed architecture with separate storage and compute

GPU acceleration for index building and search

Limitations:

Complex architecture — harder to operate

Higher minimum resource requirements

Steeper learning curve

Overkill for < 10M vectors

Best for: Large-scale deployments with billions of vectors and high throughput requirements.

Comparison Matrix

Feature	pgvector	Pinecone	Qdrant	Weaviate	Chroma	Milvus
Max vectors	~5M	Unlimited	100M+	100M+	~1M	Billions
Index types	HNSW, IVF	Proprietary	HNSW	HNSW	HNSW	HNSW, IVF, DiskANN
Filtering	SQL WHERE	Metadata	Payload	Filters	Where	Boolean expr
Hybrid search	Manual	No	Sparse+dense	BM25+vector	No	Sparse+dense
Self-hosted	Yes	No	Yes	Yes	Yes	Yes
Managed	Supabase, Neon	Yes	Yes	Yes	Planned	Zilliz
Pricing model	Free (DB cost)	Per query	Per node	Per node	Free	Per node
Language	C	Unknown	Rust	Go/Java	Python	Go/C++

Cost Modeling

For a corpus of 1 million documents (1536-dim vectors):

Database	Storage Cost	Query Cost (1K qps)	Total Monthly
pgvector (Supabase Pro)	Included	Included	~$25
Pinecone (Serverless)	~$8	~$200	~$208
Qdrant Cloud	~$65 (1 node)	Included	~$65
Self-hosted Qdrant	Server cost	Server cost	~$30-100

At 100 million documents, the picture changes dramatically:

pgvector hits performance limits

Pinecone costs scale linearly with queries

Self-hosted options need cluster management

Milvus/Zilliz becomes cost-effective

The Migration Question

Switching vector databases is painful because:

Re-embedding — If you change embedding models, all vectors must be regenerated

Index rebuilding — New database means rebuilding indexes from scratch

API changes — Different query patterns, filtering syntax, result formats

Testing — Recall and latency benchmarks must be re-validated

Mitigation strategies:

Abstract your vector operations behind an interface

Store original text alongside vectors (enables re-embedding)

Start with pgvector and migrate only when you hit real limits

Key Takeaways

pgvector is the default choice — zero new infrastructure, SQL, ACID

Pinecone for zero-ops managed service at moderate scale

Qdrant for high-performance self-hosted or managed

Weaviate for all-in-one with built-in vectorization

Chroma for rapid prototyping

Milvus for billion-scale deployments

Start simple, migrate when you have evidence of limitations

This is chapter 4 of Vector Databases & Embeddings.

Get the full hands-on course — free during early access. Build the complete system. Your projects become your portfolio.

View course details

Ch. 3: Vector Database Fundamentals

Ch. 5: Search & Retrieval Patterns