Managed pgvector is the only one of these three you can price to the dollar before you sign. That is not a claim about which database is better. It is a claim about which vendors will tell you what they charge.
As of 18 August 2026, Pinecone does not publish the hourly node rate for Dedicated Read Nodes — the capacity mode it launched precisely because the metered one gets expensive — and Qdrant publishes no per-unit rate for Qdrant Cloud on any public page at all. Both will quote you. Neither lets you check the quote against a rate card, or model next year's bill before your procurement cycle closes.
So the buying advice is not "pick the cheap one". It is: default to managed pgvector until a workload characteristic pushes you off it, and when it does, treat the unpublished rate as a contract term to negotiate rather than a price to accept.
The verdict at three workload sizes
Every figure below is modelled from the vendors' own published rates, checked on 18 August 2026. The workload is normalised across all options: 1,536-dimension float32 embeddings, one logical corpus (not partitioned across tenants), a single AWS us-east-1 region, and 10% of the corpus rewritten each month.
One asymmetry to hold on to, because it cuts against the headline number: the pgvector figures are a single instance with no replica. Pinecone's serverless tiers replicate internally at no separate line item, whereas Supabase bills each read replica at the primary's full compute price plus 1.25x its disk (read replica billing). Match the redundancy properly and Production pgvector is roughly $5,700/month with two replicas, not $1,910 — still well under Pinecone on-demand, but a third of the gap the top line implies. That correction is itself the argument in miniature: it took published per-unit rates to compute, and you cannot compute the equivalent for the other two.
| Pilot: 1M vectors, 2M queries/mo, 20 QPS | Production: 10M vectors, 20M queries/mo, 100 QPS | Scale: 100M vectors, 60M queries/mo, 300 QPS | |
|---|---|---|---|
| Managed pgvector (Supabase) | ~$236/mo | ~$1,910/mo | no published compute size fits |
| Pinecone on-demand | ~$202/mo | ~$19,716/mo — and capped at 32.6 QPS | ~$589,000/mo — capped at 3.3 QPS |
| Pinecone Dedicated Read Nodes | overkill | rate not published | ~$2,700/mo at the docs' example rate |
| Qdrant Cloud | needs 9.2 GB RAM | needs 92 GB RAM | needs 921 GB RAM |
| What the meter actually counts | — | — | — |
| pgvector | RAM-hours, idle or not | RAM-hours | RAM-hours |
| Pinecone on-demand | namespace GB × queries | same | same |
| Pinecone DRN | provisioned node-hours | node-hours | node-hours |
| Qdrant Cloud | vCPU + GB RAM + GB disk hours | same | same |
| Can you price it before signing? | pgvector yes, others no | pgvector yes, others no | nobody, at any price |
The Qdrant row has no dollar figure because Qdrant does not publish one. That is not an omission in this article. It is the finding.
Why the three quotes on your desk are not comparable
Three vendors, three meters, and only one of them moves with something you control directly.
Pinecone on-demand meters reads against corpus size. Its 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" (Pinecone docs). Ten million 1,536-dimension vectors is 61.4 GB, so every single query burns 61.4 read units before you have tuned anything. Read units run $16–$18 per million on Standard and $24–$27 on Enterprise (Pinecone pricing). Twenty million queries against that namespace is 1,228 million RUs — roughly $19,648 a month on the read line alone, at the cheaper end of the published range.
Worth flagging, because a buyer will hit it: Pinecone's own read units explainer still carries a worked example in which 50,000 vectors cost 5 RUs per query and a corpus four times larger costs about 8 — sublinear scaling that does not reconcile with the per-GB formula in the billing docs. Model from the billing docs. If a sales engineer quotes you the sublinear curve, get it in writing.
Qdrant Cloud meters resources, at rates it will not print. Its pricing page says you are "charged for compute (vCPU), memory (GB), storage (GB) consumed by your clusters, storage (GB) consumed by backups, and used inference tokens" and then routes you to a calculator instead of a rate. The billing documentation does the same. The only per-unit figure Qdrant publishes anywhere public is on its AWS Marketplace listing, where the single pricing dimension is "Qdrant cloud usage unit according to the cluster deployment" at $0.01 — a billing abstraction, not a rate. An $85 cluster arrives on your AWS invoice as 8,500 units.
Managed pgvector meters an instance. Supabase publishes every compute size with its RAM and price: Micro 1 GB at $10/month through 16XL 256 GB at $3,730, plus $0.125/GB for disk beyond the 8 GB included, on top of a $25/month Pro plan. Neon publishes $0.106 per compute-unit-hour on Launch and $0.222 on Scale, with storage at $0.35/GB-month. Amazon RDS publishes an hourly rate per instance class — db.r7g.2xlarge, 8 vCPU and 64 GB, runs about $0.96/hour, roughly $698/month single-AZ in us-east-1 for PostgreSQL (Bytebase's RDS cost index). Aurora Serverless v2 bills capacity units, and AWS's own worked example uses $0.12 per ACU-hour (Aurora pricing).
You can build a three-year model from the third group. You cannot build one from the first two.
What "no published rate" costs you in practice
Look at what fills the vacuum. Two third-party trackers both attempt to price Qdrant Cloud and land in different postcodes.
| Source | Implied cost per GB of RAM per month | Does it cite a vendor rate card? |
|---|---|---|
| LeanOps | ~$57 ($0.078/GB-hour) | No — the author's own modelling |
| RankSquire | $12.50–$25 (16 GB cluster at $200–400/mo) | No — self-described "directional estimates" |
Those two disagree by 2.3x to 4.6x, and both explicitly decline to cite a vendor page. Do not budget from either. The point is not that the trackers are careless — it is that when a vendor publishes nothing, the secondary market invents a range wide enough to swallow your business case.
At least you can size the cluster yourself. Qdrant publishes the formula: memory_size = number_of_vectors * vector_dimension * 4 bytes * 1.5, where the 1.5 covers metadata, indexes and temporary optimisation segments (Qdrant capacity planning). That gives 9.2 GB at 1M vectors, 92 GB at 10M and 921 GB at 100M. Walk into the calculator with those numbers rather than letting a sizing conversation set them for you.
Pinecone's newest mode has the same gap. Dedicated Read Nodes replace per-query read units with a fixed hourly charge — "(Node rate × shards × replicas) + storage costs + write costs" — across two node types: b1, with the vector index in memory, and t1, with roughly 4x the compute and memory at about 3x the cost. Each shard holds 250 GB, the maximum is 20 nodes per project, and the docs give $336.42/month ($0.46/hour) only as a hypothetical, noting the real node rate "varies by cloud region" and pointing at a pricing page that does not list it. Pinecone announced GA on 15 April 2026 with customer results of 77% to 97% cost reduction against on-demand — including an academic publishing platform running 200–270 QPS across 14 million vectors at 45ms p50. InfoQ's December 2025 coverage of the preview added the caveat that "on-demand indexes remain suitable for bursty or variable workloads."
The claims are plausible and the engineering is real. The rate is still unpublished.
The limit that decides this before price does
At the Production workload, Pinecone on-demand is not merely expensive. It cannot serve the traffic.
Pinecone's database limits cap query read units at 2,000 per second per index on every plan. Divide by the read units each query costs against a single namespace and you get a hard QPS ceiling that nothing in your application code can lift:
| Corpus | Namespace size | RU per query | Ceiling from the 2,000 RU/s limit |
|---|---|---|---|
| 1M vectors | 6.1 GB | 6.1 | ~327 QPS |
| 10M vectors | 61.4 GB | 61.4 | ~32.6 QPS |
| 100M vectors | 614 GB | 614 | ~3.3 QPS |
The 1M row never reaches 327 in practice: the same page caps queries at 100 per second per namespace on every plan, so that limit binds first. At 10M and 100M vectors the read-unit ceiling is already the lower of the two.
A 100 QPS requirement on a 10-million-vector corpus is off the table on on-demand at any budget. Partitioning into per-tenant namespaces collapses the RU cost to the 0.25 floor and lifts the ceiling — but only if your data genuinely partitions. One large undifferentiated corpus is exactly the shape that breaks. This is why Dedicated Read Nodes exist, and it means that for a large single-corpus workload, the only Pinecone configuration that works is the one with no public price.
Check this before you check anything else. A throughput ceiling is a go/no-go; a bill is a negotiation.
Egress and support: one is noise, one is not
The must-check list for a pricing teardown usually includes egress. Here it is, and here is why it should not drive your decision.
| Included egress | Overage | |
|---|---|---|
| Pinecone | 100 GB/mo | $0.10/GB |
| Supabase (Pro/Team) | 250 GB/mo | $0.09/GB, or $0.03/GB cached |
| Neon | 500 GB per project | $0.10/GB; $0.01/GB private network on Scale |
| Amazon RDS / AWS | first 100 GB/mo | $0.09/GB to 10 TB, then $0.085, $0.07, $0.05 (EgressCost) |
| Qdrant Cloud | not published | not published |
At the Production workload — 20 million queries returning ten ~2 KB chunks each, roughly 400 GB out — that is $30 on Pinecone, $13.50 on Supabase and zero on Neon. Real money, but rounding error against a $19,716 read line. Egress becomes a line item when your retrieval traffic leaves the provider's network at ten times this volume, or crosses availability zones at $0.01/GB each way. Model it; do not lead with it.
Support is the one that actually bites, because the tier you need is priced on a different basis by every vendor.
| Vendor | What support costs | Severity-1 response |
|---|---|---|
| Qdrant Standard | included | 4 business hours |
| Qdrant Premium | "minimum spend required" — unpublished | 1 hour, 99.9% SLA (Qdrant Cloud) |
| Pinecone Standard | free support included | not published |
| Pinecone Enterprise | $500/mo minimum usage | "Pro support included" |
| Supabase Pro | included in $25 | email only |
| Supabase Team | $599/mo flat | priority email + SLAs |
| AWS Business Support+ | 9% of spend to $10K, min $29 | (AWS Support pricing) |
| AWS Enterprise | 10% of spend to $150K, min $5,000/mo | — |
Read the first row again. Qdrant Standard answers a Severity 1 in four business hours — a Friday-evening retrieval outage gets a human on Monday. The one-hour response sits behind Premium, whose minimum spend is not published. On Supabase, upgrading a $1,910 bill from email support to priority-with-SLA costs a flat $599, a 31% surcharge. On a comparable $698 RDS instance, AWS Business Support+ adds 9%, about $63. Same requirement, four different pricing bases, and the percentage-of-spend model means the cheapest infrastructure sometimes carries the most expensive support and sometimes the least.
Price the response time you will actually need at 2AM, not the one on the plan you were shown.
Where each option loses, plainly
Managed pgvector loses at 100 million vectors. Six hundred and fourteen gigabytes of raw float32 vectors, plus an HNSW graph that typically runs 1.5–2x that again, does not fit any published managed compute size — Supabase tops out at 256 GB. pgvector's halfvec type supports up to 16,000 dimensions at two bytes each and halves the raw footprint to 307 GB, which still does not fit; bit vectors and binary quantization go further but change your recall characteristics, and that is an engineering project, not a pricing decision. At the Production workload it is an order of magnitude cheaper and prices to the dollar; at the Pilot workload the table has Pinecone on-demand marginally ahead, so "cheapest at every size" is not the claim. Above 10 million vectors you are engineering around a ceiling.
Pinecone on-demand is the clear loser at the Production workload and above — not because the product is weak, but because the meter has the wrong shape for a single large corpus. Cost scales as namespace size × query count, and the same multiplication produces a QPS ceiling you cannot buy your way past. It is genuinely good at the Pilot workload and excellent for many-small-tenant workloads, where the 0.25 RU floor applies and 1,000 tenant namespaces query for a quarter of a read unit each.
Qdrant Cloud loses the procurement round, not the technical one. Its resource-based meter is the most predictable of the three in principle — you provision RAM, you pay for RAM — and the sizing formula is public. But a CFO who needs a committed three-year number cannot get one from any public page, and if the procurement cycle closes before you extract a written rate, you have signed for a variable you never saw.
Pinecone Dedicated Read Nodes is the most interesting and the least checkable. At the Scale workload, three shards across two replicas at the documentation's example rate models to roughly $2,700/month all-in against $589,000 on-demand. If that example rate is close to real, DRN is the best answer at 100 million vectors. That "if" is the whole decision.
What actually predicts regret
Four questions, in this order. Only the last is about price.
- Does your corpus partition? If your data splits cleanly by tenant, customer or region, Pinecone's per-namespace metering is genuinely cheap and the QPS ceiling never binds. If it is one searchable pool, that model is working against you and you should know it in week one, not month nine.
- What is your sustained QPS against the largest single namespace? Compute it against the 2,000 RU/s cap before you compare any prices. It is a feasibility gate.
- Will the working set fit RAM on one published instance size? Vectors × dimensions × 4 bytes, then 1.5–2x for the graph. If yes, managed pgvector wins on cost and on the number of systems your team operates. If no, you are shopping for a distributed store.
- Can you get the rate in writing, with a cap? For Pinecone DRN, the per-node hourly rate for your region and node type. For Qdrant Cloud, the per-GB-RAM-hour, per-vCPU-hour and per-GB-disk rates, plus the Premium support minimum. Ask for a written ceiling on annual increases. A vendor that will not put a rate on a public page will usually put one in a contract, and that asymmetry is the leverage you have.
What changes the answer: a corpus that partitions flips this to Pinecone on-demand immediately. Bursty traffic — busy eight hours a day, idle the rest — favours Neon's autosuspending compute or Pinecone on-demand over any provisioned node you pay for around the clock. A data residency or licence requirement takes you off managed hosting entirely, which is a different analysis. And a published DRN rate card would make this article's conclusion obsolete, which would be a good outcome.
The Bottom Line
Fifteen years ago, cloud infrastructure buyers won a fight most people have forgotten: the right to see a public, per-unit, per-region price list and model a bill without talking to anyone. AWS published rates for everything, and the rest of the industry followed because it had to. Vector databases are quietly walking that back — not with a price increase, but with a calculator where the rate card should be and a "node rate varies by region" where the number should be.
Managed pgvector wins this comparison today on cost at 10 million vectors and on transparency at every size. But the reason to prefer it is not the $1,910. It is that you can verify the $1,910, and re-verify it next quarter, without an email thread.
If you outgrow it, buy from whichever of Pinecone or Qdrant your engineers prefer — both are real products solving real problems the extension does not. Just do not pretend you compared them on price. Make them publish the rate to you, in the contract, with a cap. What you cannot check, you cannot budget.
Continue Reading
- Pinecone vs Weaviate vs pgvector: Stay on Postgres
- Self-Host the Vector DB for Residency. Not for the Bill.
- What RAG Actually Costs: $1,308 a Month at 10M Tokens/Day
- Best RAG Platforms for Regulated Industries: Permissions First
- Best LLM Gateways for Cost Control: Self-Host First
- Claude vs GPT vs Gemini: Stop Comparing Per-Token Prices