Vector Database Comparison for LLM Apps: Pinecone vs Weaviate vs Qdrant vs pgvector

Choosing a vector store looks like a small decision until you are three months in with two million embeddings, a query pattern that filters on five metadata fields, and a bill nobody budgeted for. Pinecone, Weaviate, Qdrant and pgvector all do the same core job — store vectors, return nearest neighbours fast — but they make very different bets about who runs the infrastructure, how filtering behaves once your index grows, and what you actually pay for.

Here is the comparison I would want before committing a project to one of them.

Hosting and control: who runs the servers

The first fork in the road is whether you can run the thing yourself. Pinecone is managed-only. There is no self-hosted edition, no Docker image, no air-gapped deployment. That is a real constraint if you work in healthcare, finance or government, or if a client contract says data never leaves a specific region. In exchange, you get a working index in minutes and never touch a shard.

Weaviate and Qdrant are both open source with managed cloud options, so you can prototype on someone else's servers and move in-house later — or the reverse. Weaviate ships under a permissive licence with a cluster you can run on Kubernetes; Qdrant is a single Rust binary that is unusually easy to reason about operationally, plus a hybrid cloud option where the control plane is managed but the data plane sits in your own VPC.

pgvector is the odd one out: it is not a database at all but an extension inside PostgreSQL. There is nothing new to operate, because you already operate Postgres. If you use RDS, Supabase, Neon or a self-managed cluster, CREATE EXTENSION vector is roughly the entire installation story.

Scaling: how each store grows

Pinecone's serverless indexes separate storage from compute, so a quiet index costs little and a busy one scales without resharding by hand. Namespaces let you isolate tenants or environments without duplicating the schema. Older pod-based indexes still exist for workloads that need predictable throughput.

Weaviate scales horizontally with sharding and replication and has first-class multi-tenancy, where each tenant gets its own isolated storage. That matters if you are building one deployment for two hundred customers and want to delete one cleanly.

Qdrant's advantage is memory efficiency. It memory-maps vector data and supports scalar, product and binary quantization, which can shrink a collection enough to fit on a much smaller machine. Replication and sharding are built in, and payload-based partitioning gives you another lever for large multi-tenant sets.

pgvector scales the way Postgres scales: bigger instance, read replicas, table partitioning. HNSW index builds are memory-hungry and can take a while on large tables, so plan the build window. For a few hundred thousand to a few million vectors, this is rarely the bottleneck people fear. Beyond that, it depends entirely on how much RAM you are willing to buy.

Filtering and hybrid search: where architectures get decided

Filtering is the feature that quietly determines your schema. Many vector stores do post-filtering, meaning they fetch nearest neighbours first and discard the ones that fail your filter. If only 2% of your data matches, you can end up with very few results or an expensive over-fetch.

Qdrant handles this well. Payload fields can be indexed and filters are applied during the search, including nested conditions and range queries — useful when you need "documents from this workspace, updated this year, tagged legal". Weaviate also filters natively and adds hybrid search out of the box, blending BM25 keyword scores with vector scores. For documentation search or product catalogues, that combination frequently beats pure vector search, because users still type exact model numbers and error codes.

Pinecone supports metadata filters and namespaces with reasonable flexibility, though complex boolean logic across many fields is less expressive than what you get from the open-source options.

pgvector is different in kind. Filtering is just SQL. You can join against your users table, respect row-level security, use transactions, and combine vector distance with ordinary WHERE clauses in a single query. The catch: the Postgres planner may decide a sequential scan beats your index when a filter is not selective, so test with realistic data rather than a clean benchmark table.

The cheapest vector database is usually the one your team already knows how to operate at three in the morning.

Cost: where the money actually goes

Pinecone bills on usage or on provisioned capacity. The trap is not storage — it is read and write volume. Chatty applications that query on every keystroke, or pipelines that re-upsert the entire corpus nightly, can run up costs fast. Batch your writes and cache repeated queries.

Weaviate and Qdrant self-hosted convert licence fees into infrastructure and engineering time. That is a genuine trade, not a free lunch: someone has to handle upgrades, backups and failover. Their cloud tiers remove that burden at the usual managed-service premium.

pgvector has no separate invoice, which is why teams love it. But the cost hides in your Postgres bill: extra RAM, larger storage, longer backups, and the read replica you add when queries start competing with your transactional traffic. Put vector search on a dedicated instance or replica if your main database is latency-sensitive.

Feature snapshot

• Pinecone: fully managed, serverless and pod-based indexes, metadata filters, namespaces, sparse-dense hybrid search. No self-hosting.
• Weaviate: open source, GraphQL and REST APIs, hybrid BM25 plus vector search, modules for vectorization, strong multi-tenancy.
• Qdrant: open source in Rust, rich payload filtering with indexed fields, quantization for memory control, sparse and named vectors.
• pgvector: Postgres extension, HNSW and IVFFlat indexes, SQL joins and transactions, backups with your existing tooling.

How to pick without overthinking it

Start from your constraints, not from benchmarks. Ask three questions: where must the data physically live, how many vectors will you have in twelve months, and who will be on call when the index misbehaves?

If your embeddings live happily beside your relational data and you are under a few million vectors, pgvector is the pragmatic default. You ship faster and add one fewer system to monitor. If you need heavy metadata filtering on a large collection and want to self-host on modest hardware, Qdrant is the strongest fit. If keyword-plus-vector hybrid search and tenant isolation are day-one requirements, Weaviate saves you from building those pieces. If your team has no appetite for infrastructure and the budget exists, Pinecone removes an entire category of work.

Two habits make any of these choices cheaper to reverse. First, wrap your vector calls in a thin internal interface — upsert, search, delete — so swapping the backend is a week of work rather than a quarter. Second, test recall on your own data with your own filters before you commit. Build a small evaluation set of real queries with known correct answers, then measure how often the right document appears in the top five. That number will tell you more than any comparison table, including this one.

Photo: congerdesign / Pixabay