You have a retrieval-augmented generation proof of concept that works on a laptop. The embeddings are in a CSV file, the search is brute force, and the demo impresses the steering committee. Now someone asks the obvious question: what happens when this goes to production? The answer, almost always, is that brute-force cosine similarity over a Pandas dataframe stops being funny around 100,000 vectors and becomes impossible somewhere past a million. You need a real vector database. This post compares the four options we see most often in serious mid-market evaluations — pgvector, Pinecone, Weaviate, and Qdrant — and gives you a decision framework grounded in the dimensions that actually matter in production: indexing strategy, scale characteristics, operational complexity, and cost model.

Why the Vector Database Decision Is Harder Than It Looks

Vector search looks like a solved problem from the outside. Pick a database, load your embeddings, run a query. In practice, the choice determines your recall at scale, your p99 latency under load, how much infrastructure your team has to operate, and how predictable your monthly bill will be. Two teams using the same embeddings model on different databases will end up with very different systems — different recall ceilings, different operational burdens, and very different cost curves as the corpus grows.

The mistake we see most often is optimizing for the demo and ignoring the steady state. A managed service that ships a working index in an afternoon can become expensive or inflexible at 50 million vectors. A self-hosted option that looks cheap on a pricing page can absorb a surprising amount of engineering time once you factor in upgrades, reindexing, and on-call rotation. Choose the database that matches your team’s shape and your corpus’s growth trajectory, not the one with the most polished marketing site.

The Four Options in Brief

These four options represent four distinct points on the spectrum between “database you already have” and “purpose-built managed service.” Understanding where each sits on that spectrum matters more than memorizing benchmark numbers, because the spectrum determines what will be easy and what will be painful at scale.

pgvector: Vectors Inside Your Existing Postgres

pgvector is a Postgres extension that adds vector types and similarity search operators to a database you almost certainly already run. You store embeddings in the same tables as your application data, join them against business records with ordinary SQL, and query them with the same connection pool your application already uses. The appeal is obvious: no new system to operate, no separate source of truth, no replication pipeline to keep in sync.

The trade-off is that Postgres was not designed for high-throughput approximate nearest neighbor search. pgvector’s HNSW index is solid and improving quickly, and for corpora up to a few million vectors with moderate query volume, it performs well. Beyond that, you start fighting the database. Index rebuilds compete with OLTP traffic for memory and CPU, vacuum behavior degrades on large tables, and the single-node architecture limits horizontal scaling. pgvector is best when you want vector search colocated with transactional data and your corpus is bounded.

Pinecone: Fully Managed, Opinion-First

Pinecone is a fully managed, proprietary vector database. You do not run servers, you do not tune indexes, and you do not handle reindexing. You create an index, upsert vectors, and query. The operational surface is intentionally small, and for teams without infrastructure capacity, that is a genuine advantage — the path from prototype to production is shorter here than anywhere else.

The trade-off is control and cost predictability. Pinecone’s serverless model bills on a combination of storage, reads, and writes, and the pricing can be opaque at scale. You also give up the ability to colocate metadata filters with vector search at the query layer in arbitrary ways; Pinecone supports metadata filtering, but complex joins against business data require syncing a second system. Pinecone is best when your team cannot operate infrastructure and your access pattern is a clean vector-search workload without heavy relational joins.

Weaviate: Open Source With a Graph bent

Weaviate is an open-source vector database with a permissive license, a rich module ecosystem, and a strong story for hybrid search — combining keyword (BM25) and vector retrieval in a single query. It supports both self-hosting and a managed cloud offering, which gives you a credible exit ramp if the managed service ever stops fitting. The data model is object-oriented, with classes and properties, which maps well to document-style corpora.

The trade-off is operational weight on the self-hosted path and a steeper learning curve on the query language. Weaviate’s GraphQL-flavored API is expressive but unfamiliar to teams used to SQL or simple REST, and tuning hybrid search weights is more art than science. Weaviate is best when hybrid search is a first-class requirement and you want the option to self-host later.

Qdrant: Rust-Native and Performance-Focused

Qdrant is an open-source vector database written in Rust, with a strong emphasis on throughput, memory efficiency, and filterable vector search. It supports self-hosting and a managed cloud, and its payload filtering — applying structured filters alongside vector search without sacrificing recall — is among the best in the field. The API is clean and REST-first, which lowers the on-ramp.

The trade-off is that Qdrant is younger than the others in production at scale, and its ecosystem of integrations and tooling, while growing fast, is not as deep as Weaviate’s or Pinecone’s. Qdrant is best when query throughput and filtered search performance are the dominant constraints and your team is comfortable running or contracting for infrastructure.

Indexing Strategies: The Decision Underneath the Decision

The choice of approximate nearest neighbor (ANN) index is arguably more important than the choice of database, because the index determines recall, latency, and memory footprint. Most serious vector databases have converged on two families, and understanding the trade-offs helps you read benchmark numbers critically.

HNSW: Fast Queries, Expensive Builds

Hierarchical Navigable Small World (HNSW) graphs are the dominant index in production today. They offer excellent query latency and high recall, at the cost of high memory usage (the graph is held in RAM) and slow, memory-intensive index construction. pgvector, Weaviate, Qdrant, and Pinecone all offer HNSW variants. For most workloads under a few tens of millions of vectors, HNSW is the right default.

The main operational concern with HNSW is memory. The graph plus the raw vectors must fit in RAM for good performance, which makes HNSW expensive per vector and forces sharding earlier than you might expect. When the corpus grows beyond what a single node can hold in memory, you are into distributed HNSW territory, where query fan-out and network latency start to matter.

IVF and Quantization: Lower Memory, Tunable Recall

Inverted File (IVF) indexes, often combined with product quantization (PQ) or scalar quantization (SQ), trade some recall for dramatically lower memory and faster builds. Quantization compresses vectors — PQ aggressively, SQ more modestly — which lets you fit far more vectors per node. The trade-off is measurable recall loss and additional tuning parameters (centroid counts, quantization block sizes).

IVF-with-quantization is the right choice when the corpus is large, memory budget is tight, and you can tolerate a few percent of recall loss in exchange for fitting the index on affordable hardware. It is also the basis for several databases’ disk-based or tiered-storage indexes, which push the cost curve down at the price of higher latency.

The Practical Takeaway

Most teams should start with HNSW at default parameters and only move to quantized IVF once memory cost or build time becomes a real constraint. Chasing the last few percent of recall through index tuning is rarely worth the engineering time; re-examining the embedding model or chunking strategy usually yields more.

Comparing the Dimensions That Matter

Scale Characteristics

Scale is where the four options diverge most sharply, and the divergence is usually underpriced in evaluations.

pgvector scales well to a few million vectors per table on appropriately sized hardware. Beyond that, index memory pressure, vacuum overhead, and the lack of horizontal scaling push you toward sharding at the application layer or moving to a dedicated system. We worked with a legal-tech company that started on pgvector at 800,000 vectors and watched query latency double every quarter as the corpus grew. They crossed three million vectors and found themselves running nightly reindex jobs that consumed so much memory that their transactional queries started timing out during the build window. The day they migrated to Qdrant, the timeouts stopped.

Pinecone takes the opposite approach. It is designed for scale from the start, with serverless tiered storage that can handle hundreds of millions of vectors without you thinking about nodes or shards. The trade-off is that query latency on cold tiers is noticeably higher, and the cost model shifts in ways that are hard to predict as you scale. A media company we advised loaded 40 million article embeddings into Pinecone and were pleased with the simplicity until their monthly bill tripled after a traffic spike pushed previously cold vectors into the hot tier. The managed-scale story is real, but the pricing curve rewards teams that understand their access patterns.

Weaviate scales horizontally with a sharded, replicated architecture. Self-hosted scaling is real engineering work — you need to plan shard counts, replica factors, and resource allocation per node, and getting it wrong means re-sharding later under load. Managed Weaviate Cloud handles much of that for you, which makes the self-hosted option more attractive as a starting point with a credible exit to managed if the operational burden grows.

Qdrant also scales horizontally with a sharding model, and it is notable for efficient resource use per node. In practice, this translates to lower node counts at a given throughput, which matters when each node is a cost line item. A recommendation team we worked with found that Qdrant handled the same query volume as their previous Weaviate cluster on two-thirds the nodes, purely because the Rust runtime used memory more efficiently.

The honest summary: if you expect to stay under five million vectors indefinitely, all four are viable. If you expect to cross 50 million within a year, pgvector is the wrong starting point and Pinecone’s managed scale story is the most hands-off.

Operational Complexity

Mid-market teams consistently underestimate this dimension. All four options will run a demo. None of them run themselves in production.

pgvector has the lowest operational delta if you already operate Postgres — there is no new system to learn, no new on-call rotation, no new upgrade path. The complexity hides in the database you already run: vector indexes stress the same memory and CPU budgets as the rest of your workload, and a poorly tuned HNSW build can degrade OLTP latency. Pinecone has the lowest operational surface of any option because there is effectively nothing to operate. The cost is that when something goes wrong, you are entirely dependent on the vendor’s diagnostics. Weaviate and Qdrant, when self-hosted, sit in the middle: real systems to operate, with monitoring, backups, upgrades, and capacity planning, but with credible managed cloud options that remove most of that burden if you prefer.

Cost Models

Cost is where vendor pricing pages mislead most often, because the units differ and the dominant cost driver depends entirely on your workload.

pgvector costs are essentially your existing Postgres costs plus larger instances to hold the index in memory. This is the most predictable cost model of the four, because you are already paying for the database and the vector index just means you need more RAM. The per-vector cost rises with the corpus because memory is the expensive resource, and HNSW graphs live in RAM. For a team that already operates Postgres, the marginal cost of adding vector search can be close to zero at small scale, which is why pgvector is the most common starting point we recommend.

Pinecone bills on a combination of storage, reads, and writes in a serverless model. At small scale the pricing is low and predictable enough that teams rarely think about it. At high read or write volume the costs can steepen rapidly, and the pricing is harder to model in advance because it depends on access patterns you may not fully understand until you are in production. The team that got burned by the cold-tier promotion we mentioned earlier is a good example — they modeled costs based on steady-state traffic and were blindsided by a viral content push that changed their access pattern overnight.

Weaviate Cloud and Qdrant Cloud bill on instance size and storage, which is more predictable than serverless pricing but requires you to size your instances correctly. Oversizing wastes money; undersizing means latency spikes or outages during traffic peaks. The self-hosted versions of both cost whatever your infrastructure provider charges plus the engineering time to operate them, and that second cost is the one most teams forget to budget for.

The hidden cost everywhere is engineering time. A self-hosted vector database run by a team without dedicated platform capacity will cost more in staff hours than a managed service saves in infrastructure. We have seen teams spend the equivalent of a full-time engineer’s salary on operating a self-hosted Weaviate cluster that a managed cloud instance could have replaced for a fraction of the cost. When you model the total cost of ownership, include the hours your team will spend on upgrades, monitoring, capacity planning, and incident response — not just the cloud bill.

Benchmark Methodology: Why Most Comparisons Mislead

Public vector database benchmarks are useful for narrowing the field and nearly useless for making a final decision. The reason is that benchmark results are dominated by factors that vary with your workload, not the database’s intrinsic quality: corpus size and dimensionality, embedding distribution, selectivity of metadata filters, read-to-write ratio, and the recall target you consider acceptable. A benchmark run on 10 million random vectors with no filters tells you almost nothing about how the same databases will perform on your 30 million-row corpus with heavy pre-filtering and a 95% recall requirement.

The right approach is to run your own benchmark on a representative sample of your real data. Define the metrics that matter to your application — typically recall@k at a fixed latency budget, p99 latency under target query load, and cost per million queries — and measure all candidate databases against the same dataset and the same workload. Control the obvious variables: identical embeddings, identical hardware for self-hosted options, identical filter selectivity, and identical recall targets before you compare latency.

Be explicit about what you are measuring and what you are not. Most production failures we see are not recall failures; they are operational failures — a reindex that took the system down, a managed-service quota that surfaced at peak load, a cost spike nobody modeled. Weight your evaluation toward the failure modes you cannot afford, not the benchmark numbers that look best in a slide.

Decision Framework: Which Database Fits Your Workload

The table below is the one we walk mid-market clients through. It is not a ranking. It is a matching exercise between your constraints and each database’s center of gravity.

Dimension	pgvector	Pinecone	Weaviate	Qdrant
Best fit	Colocated search, bounded corpus	No-infra teams, clean search	Hybrid search, self-host option	High throughput, filtered search
Scale ceiling (single system)	A few million	Hundreds of millions	Tens of millions (sharded)	Tens of millions (sharded)
Operational burden	Low if Postgres exists	Minimal	Moderate self-hosted	Moderate self-hosted
Cost predictability	High (existing infra)	Low at scale	Moderate	Moderate
Hybrid search	Via SQL + keyword	Limited	First-class	Good with payloads
Managed option	Via cloud Postgres	Fully managed	Weaviate Cloud	Qdrant Cloud
When to choose it	<5M vectors, SQL joins matter	Ship fast, no platform team	Hybrid search is core	Throughput is the constraint

Use the table as a forcing function, not an answer. If your corpus will stay bounded and your vectors live next to transactional data, pgvector keeps the system simple and the joins cheap. If you need to ship in weeks and have no one to run infrastructure, Pinecone is the fastest path. If hybrid search is a first-class requirement and you want a self-host exit ramp, Weaviate is the natural fit. If filtered vector search at high throughput is the dominant constraint, Qdrant is the strongest contender.

A Pragmatic Recommendation

Most mid-market teams we work with start on pgvector and stay there longer than they expect. For corpora under a few million vectors with moderate query volume, colocating embeddings with the application database removes an entire class of operational and consistency problems, and the performance is good enough that the database is rarely the bottleneck. The common exit trigger is scale — once the corpus or the query rate pushes the index off affordable memory, or once reindexing starts competing with OLTP traffic, it is time to move.

When that move happens, the choice between Pinecone, Weaviate, and Qdrant is usually settled by two questions. Can your team operate infrastructure, or do you need a fully managed service? And is your workload a clean vector search, or does it require hybrid retrieval and heavy filtering? Fully managed and clean search points to Pinecone. Self-hosted or hybrid search points to Weaviate. Throughput- and filter-dominated workloads point to Qdrant. Run a short benchmark on your own data before committing, and weight the operational and cost dimensions more heavily than the recall numbers — those are the dimensions that determine whether the system survives its second year in production.

What to Do Next

Whichever database you pick, the same discipline applies. Measure recall and latency on a representative sample of your real data before you commit. Load-test at your target query volume, not just your average volume. Model cost at 3x and 10x your current corpus, not just today’s size. And assign a named owner for the database from day one — the system that nobody owns is the system that fails in production.

The vector database is a means to an end. The end is retrieval that is fast enough, accurate enough, and cheap enough to support the application your users actually rely on. Pick the database that gets you there with the least operational drag, ship something bounded this quarter, and let the measured result drive the next decision.