If you already run Postgres and you have fewer than about 10 million vectors, install pgvector and stop reading vendor comparison pages. The second system is the cost, not the licence. Above 10 million vectors on a single corpus, the question stops being how big and becomes what shape — and the shape of your workload moves your bill by two orders of magnitude on the same data.
Here is the number that should decide this for you. Pinecone's own billing documentation states that "a query uses 1 RU for every 1 GB of namespace size, with a minimum of 0.25 RUs per query." Ten million 1,536-dimension vectors is roughly 64 GB. Against one namespace, every single query costs 64 read units. Against a thousand tenant namespaces of 64 MB each, every query costs 0.25 — the documented floor. Same vectors, same queries, 256x difference on the read line.
Nobody's benchmark tells you that. Their pricing page does.
The verdict at 10M vectors, 20M queries a month
All prices checked against the vendors' live pricing pages on 2 August 2026. The workload is normalised: 10 million vectors at 1,536 dimensions, 20 million queries per month, 2 million records rewritten per month, 200 QPS at peak.
| pgvector | Pinecone | Weaviate | |
|---|---|---|---|
| Modelled monthly cost | $960–$1,870 (instance) | $157 partitioned / $20,557 single namespace | ~$256 at $0.01668/1M dims, before replication |
| What you actually pay for | RAM, 24/7, queried or not | reads, scaled by namespace size | dimensions stored |
| Bill moves with | corpus size | query volume × namespace size | corpus size |
| 200 QPS on one corpus? | yes, if it fits RAM | no — 31 QPS cap | yes |
| Hybrid search | build it yourself, no BM25 | sparse index, 10 upserts/sec | native BM25F, best of the three |
| Ops burden | yours (index builds bite) | none | none managed / real self-hosted |
| Licence | PostgreSQL licence | proprietary | BSD-3-Clause |
| Don't pick it if | corpus > RAM budget | one big undifferentiated corpus | you need one bill you can predict |
The recommendation: stay on pgvector until one of three specific things is true — your working set no longer fits an instance you're willing to pay for, you need genuine BM25 relevance, or you have more than ~50,000 tenants. None of those is "we hit a million vectors."
The loser for this buyer is Pinecone, and not because it is a bad database. It is the best-engineered product of the three at what it is for. But its pricing model charges you for corpus size on every query, which punishes precisely the shape most enterprises have: one large document corpus, moderate QPS, already sitting next to Postgres. If your data does not partition into natural tenants, Pinecone's economics work against you and no amount of tuning fixes it.
Why the read unit is the only Pinecone number that matters
A read unit is Pinecone's billing unit for query, fetch and list operations — the docs define it as a measure of "the compute, I/O, and network resources consumed." Storage is nearly free at $0.33/GB/month on the Standard plan; writes are $4–$4.50 per million write units. Reads are $16–$18 per million on Standard and $24–$27 on Enterprise, and reads are where the entire bill lives.
Run the arithmetic on our workload. Pinecone's storage formula is records × (ID size + metadata size + dense vector dimensions × 4 bytes). Ten million records with a 20-byte ID and 200 bytes of metadata comes to about 64 GB.
One namespace: 64 RU per query × 20 million queries = 1.28 billion read units. At $16 per million, that is $20,480 a month — plus $21 of storage and $56 of writes.
One thousand namespaces of 64 MB: each is under the 0.25 GB threshold, so every query bills the 0.25 RU minimum. 20 million queries × 0.25 = 5 million RU = $80 a month. Total bill, about $157.
The same ten million vectors. The same twenty million queries. A 130x difference in the invoice, decided entirely by whether your data has a tenant key.
Then there is the wall behind the bill. Pinecone's published limits cap query read units at 2,000 per second per index. At 64 RU per query, that is 31 queries per second — against a namespace holding your whole corpus, you cannot reach 200 QPS at all. Not "it gets expensive." You are architecturally capped and must shard into indexes or namespaces to proceed.
This is the honest steel-man for Pinecone, and it is strong: if you are a B2B SaaS company where every query is naturally scoped to one customer, all of the above inverts. You get per-tenant isolation, the 0.25 RU floor, up to 100,000 namespaces per index on Standard and Enterprise, and zero operational work. That is a genuinely excellent product at $157 a month. Just know that you are buying a multi-tenant router, and that the tenant key is what makes it cheap.
Do not pick Pinecone if: your corpus is one undifferentiated pile of documents, your QPS is high, or you cannot state today what your namespace key would be.
What pgvector actually costs, honestly
The pgvector cost story is not "it's free." It is an extension under the PostgreSQL licence, and the extension is free. The RAM is not.
HNSW indexes want to live in memory. Crunchy Data measured that "the index for 1M rows of AI embeddings can be 8GB or larger" and takes around six minutes to build at that size. Ten million 1,536-dimension vectors is ~61 GB of raw vector data before the graph. To keep that resident you are looking at a 128 GB machine — Supabase's published compute pricing puts an 8XL (32-core, 128 GB) at $1,870/month. Use halfvec, which the pgvector README documents at "2 × dimensions + 8 bytes" instead of four, and you halve the vector footprint into a 64 GB box at $960.
So at our normalised workload, pgvector is the most expensive of the three. That is the finding people skip, and it is why this is not a free-software argument. You pay for that RAM at 3am on a Sunday when nobody is querying.
Now run it at one million vectors instead. Pinecone's index is 6.4 GB, so a single namespace bills 6.4 RU per query: 20 million queries comes to $2,048/month. pgvector fits comfortably on a 2XL at $410. Below roughly a million vectors it usually fits inside an instance you are already paying for, and the marginal cost is zero.
The crossover is not a vector count. It is the point where dedicated RAM costs more than metered reads — and that lands anywhere between 1M and 50M vectors depending entirely on your query volume and whether you partition.
Two things genuinely improved here recently, and both are worth knowing before you rule pgvector out. Iterative index scans arrived in 0.8.0, and AWS measured the effect on Aurora across 10 million products with 384-dimension embeddings on db.r8g.4xlarge instances: p99 latency on a top-10 query fell from 123.3ms to 13.1ms in relaxed-order mode, and — this is the important half — recall on category-filtered queries went from 10% to 100%, and from 1% to 100% on complex filtered searches. Before 0.8.0, pgvector under a selective WHERE clause silently returned mostly wrong answers. If you evaluated pgvector before late 2024 and rejected it on filtered recall, you evaluated a different product.
The second is that pgvector holds up on raw speed. Supabase benchmarked it against Pinecone on 1 million 1,536-dimension OpenAI embeddings and reported over 4x the QPS of a three-pod p1.x2 setup at accuracy@10 of 0.99, for $70 a month less. That is a vendor benchmark on a vendor's own product, and it dates to October 2023 against Pinecone's since-retired pod architecture — treat it as directional, not current. But the direction has held up in practitioner accounts: Confident AI's writeup of replacing Pinecone with pgvector put the deciding factors not on speed at all but on network latency, the 40 KB metadata ceiling forcing a second round-trip to the primary database, and indexes drifting out of sync with the source of truth under load.
That last one is the real argument for pgvector and it never shows up in a benchmark. Your embeddings and your rows commit in the same transaction. No sync job, no drift, no reconciliation runbook.
Do not pick pgvector if: your working set will not fit the largest instance you are willing to buy, you have no one who will own maintenance_work_mem, or you need BM25-quality keyword relevance.
The operational burden nobody puts in the comparison table
The pgvector tax is not query tuning. It is index builds.
There is a specific cliff, and a pgvector issue captures it exactly in the warning Postgres emits: NOTICE: hnsw graph no longer fits into maintenance_work_mem after 5908085 tuples. Cross that line and the build spills to disk and runs an order of magnitude slower. The default maintenance_work_mem is 64 MB. Nobody discovers this during a proof of concept on 100,000 rows; everybody discovers it the first time they reindex 10 million rows in production.
Plan for it deliberately. Size maintenance_work_mem to hold the graph, build indexes concurrently, and treat a full HNSW rebuild as a scheduled maintenance window rather than something you fire off on a Tuesday afternoon. This is a solved problem, but it is solved by a person, and that person's time is the real price difference between pgvector and a managed service.
Weaviate is BSD-3-Clause and genuinely self-hostable, which sounds like the best of both worlds and mostly isn't. Self-hosting it means you own a distributed system — provisioning, backups, version upgrades, shard rebalancing — which is strictly more operational surface than adding an extension to a database you already operate. Self-host Weaviate because you need data residency or air-gapping, not because you want to save money.
Pinecone's operational burden is genuinely zero, and that is worth real money. It is just not worth $20,000 a month.
Hybrid search is where pgvector is actually weak
Every vendor claims hybrid search. Only one of these three is good at it.
Hybrid search means combining semantic vector similarity with keyword matching, so that a query containing a part number or a proper noun does not get semantically approximated into the wrong document. It is the single highest-leverage retrieval improvement most RAG systems have left, which is why this deserves more weight than it usually gets.
Weaviate wins outright. Its hybrid search fuses vector results with BM25F keyword results natively, with Relative Score Fusion as the default since v1.24 and an alpha parameter that slides from pure keyword (0.0) to pure vector (1.0). One query, one system, tunable relevance. If hybrid retrieval quality is your binding constraint, this is the reason to pay Weaviate.
Pinecone supports it with limits you must read first. Sparse vectors are capped at 1,000 non-zero values, with a maximum of 10 sparse upserts per second and 100 sparse queries per second per index. Ten writes per second is not a rate limit you tune around — it is a constraint on your entire ingestion architecture.
pgvector does not have BM25, and the workaround is real work. Jonathan Katz demonstrated the canonical recipe — run full-text search and vector search separately, UNION ALL them, and combine with Reciprocal Rank Fusion — and it executes in 8.553ms on his test set. He also states plainly that the evaluation used randomly generated data with no ground truth. The deeper problem is that Postgres's native ts_rank is not BM25: as ParadeDB explains, native ranking functions "only consider individual documents in isolation: they don't understand global corpus statistics," so they cannot tell a term appearing in 80% of your documents from one appearing in 5%. Extensions like pg_search and pg_textsearch close that gap, but now you are evaluating extensions, and the "one system" argument weakens.
Multi-tenancy: the feature that is actually a pricing model
For anyone building B2B software, this section decides the whole question, because tenancy is not really an isolation feature here. It is the unit of billing.
Pinecone uses namespaces, and as established above, the namespace is what sets your read-unit cost per query. Small namespaces are cheap and fast; one giant namespace is neither. The design and the invoice point the same direction, which is good engineering.
Weaviate has the most serious implementation. Tenants are first-class, with documented states — ACTIVE, INACTIVE, OFFLOADED — and offloading cold tenants to S3 since v1.26, so dormant customers stop consuming RAM without being deleted. Weaviate claims support for "over a million tenants per cluster without noisy neighbor issues." Treat the number as a vendor claim; treat the tiered hot/warm/cold architecture as the genuine differentiator, because a long tail of inactive tenants is exactly what a per-GB-of-RAM model handles badly.
pgvector does tenancy the Postgres way: partition by tenant and enforce isolation with row-level security, a pattern AWS documents in detail. This is genuinely excellent at hundreds or low thousands of tenants, and the isolation guarantee is stronger than anything above it — FORCE ROW LEVEL SECURITY cannot be bypassed by the application layer, which matters when your auditor asks. It degrades at very high tenant counts, because every partition wants its own HNSW index and they all compete for the same shared_buffers. Somewhere around tens of thousands of tenants, the Postgres answer stops being elegant.
The rule: under ~1,000 tenants, partitioned Postgres. Over ~50,000 with a long dormant tail, Weaviate. In between, whichever system your team can actually operate.
What changes this answer
The comparison above assumes vectors live in RAM, because for all three of these systems they do. That assumption is the one under active attack.
turbopuffer builds on object storage with an SSD cache, with tier minimums of $16, $256 and $4,096 per month, and prices closer to S3 economics for data at rest. For a large corpus at moderate QPS — the exact shape that makes Pinecone expensive and pgvector RAM-hungry — that architecture is structurally cheaper than anything priced on provisioned memory. Qdrant and Zilliz are moving the same way, and MongoDB has made the consolidation argument from the other direction.
Three things should make you revisit this decision:
- Your embedding dimension changes. Every cost model here scales linearly with it. Moving from 1,536 to 3,072 dimensions doubles your Weaviate bill, your Pinecone read units and your pgvector RAM in one release note.
- Your query pattern gains a tenant key. The day your workload partitions naturally, Pinecone's economics flip from worst to best.
- Filtered recall becomes the complaint. If users report that results are wrong rather than slow, the fix is iterative scans and relevance tuning, not a migration. Teams switch vendors over this constantly, and it is usually a configuration problem wearing a procurement costume.
Do This in the Next 30 Days
This week: compute your read-unit exposure before you sign anything. Corpus size in GB × queries per month × $16 per million. If you cannot name your namespace key in one sentence, you have your answer about metered vector databases.
This month: run pgvector against your real corpus, not a sample. Set maintenance_work_mem high enough to hold the graph, build with HNSW, and measure recall under your actual WHERE clauses — on pgvector 0.8.0 or later, or you are measuring a bug that has been fixed.
Before you renew: price the same workload three ways with your real numbers, and make the hybrid-search decision explicitly rather than discovering in month four that keyword relevance was the requirement all along.
The Bottom Line
The vector database market spent three years selling scale as the axis of comparison, and scale is the wrong axis. Ten million vectors is cheap or ruinous depending on one property of your data that no benchmark measures: whether queries partition. A specialised system earns its place when it does something your existing database cannot, and for most enterprise RAG workloads under 10 million vectors, pgvector already does the thing.
This is the same argument the industry had about search engines in 2010 and about time-series databases in 2018. It ended the same way both times — the specialised system won the extreme cases and Postgres absorbed the middle, which is where nearly everyone actually lives.
Buy the second system when it removes a constraint you can name. Not when it removes a number you find impressive.
Continue Reading
- RAG Fails 40% of the Time. The Fix Isn't a Better Model.
- Why 20 Banks Chose MongoDB to Fix Enterprise AI Retrieval
- MongoDB 8.3 Kills the 4-Database AI Agent Stack
- AI Agents Broke Meta's Stack. Yours Is Next.
- Nvidia's $400M Kumo Bet: LLMs Can't Touch Your Database
- 92% of CFOs Can't Justify AI Spend. McKinsey Has a Fix.