Vector Database Comparison: Pinecone vs Weaviate vs pgvector at Three Scales

A 1,536 dimension embedding occupies 6,152 bytes inside Postgres. One million of them is 6.2 GB, which fits in the memory of a database server you are almost certainly already paying for. That single arithmetic fact settles most of any vector database comparison, because it decides whether the other two options are bidding for a job that actually exists.

What each system actually charges you for

The three products do not sell the same unit. That is the reason most published comparisons produce numbers nobody can reconcile.

Pinecone sells operations. Weaviate sells stored dimensions. pgvector sells nothing, because it is an extension, so what you are really buying is a Postgres server large enough to hold the index in memory.

Pinecone and Weaviate rates are from the vendors' own public pricing pages. Postgres compute prices are Supabase list prices, used here because they are published per instance size and therefore checkable. Any managed Postgres provider works the same way.

Pinecone bills four meters, and one of them surprises people

Storage and writes behave the way you would guess. Reads do not. A query consumes 1 read unit for every 1 GB of namespace size, with a floor of 0.25 read units per query.

Read that again, because the pricing consequence is large. You are billed for the size of the haystack, not for the number of needles you asked for. Returning 5 results from a 60 GB namespace costs the same as returning 500.

Weaviate bills dimensions, which makes the model unusually predictable

Weaviate Cloud charges per million vector dimensions stored. Multiply your record count by your embedding width and you have the bill, before minimums.

The catch is the word "from" in front of every rate. Weaviate states that dimension pricing varies by index type, compression method and region, so the published figures are floors rather than the price you will pay. Ask for a written quote against your actual index configuration before you model anything on them.

pgvector bills you for a machine, which changes the comparison

There is no vector line item. There is a Postgres instance, and the question is whether it has enough memory to keep the index resident.

This is why the standard comparison is unfair in both directions. Against a greenfield deployment, pgvector looks expensive, because you are pricing a whole database server against a usage meter. Against an application that already runs on Postgres, pgvector is nearly free, because the marginal cost is one compute tier.

Modelled monthly cost at three data scales

Every figure below is modelled from published rates, not taken from an invoice. The assumptions are stated so you can rerun them with your own numbers.

Assumptions: 1,536 dimension float32 embeddings, 1 million queries per month, a single region, and no replicas. Write units, egress, backups and engineering time are excluded from every column. Postgres instances are sized so that memory is roughly twice the raw vector bytes, which is a working rule of thumb for keeping an HNSW index resident, not a measured requirement.

The two Pinecone columns hold the data identical and change only how it is partitioned. That is the largest single lever in this table, and it is a configuration choice rather than a product difference.

Two readings of that table are worth separating. The first is that Postgres is the most expensive option at 10 million records and above, which is the opposite of what most posts on this subject conclude. The second is that the Postgres column is a total, while the others are additions to a bill you are already paying.

If your application already runs on a Postgres instance with 8 GB of memory, the honest number at 1 million vectors is the upgrade, not the total. That is about $100 a month, which lands in the same place as the Pinecone column. It also adds no new vendor, no new client library and no second copy of your data to keep in sync. Under 5 million vectors, I would not add a second database. The comparison that matters is the compute tier, and the operational simplicity is worth more than the difference.

Read units scale with namespace size, not query complexity

This is the most consequential detail in Pinecone's pricing and the least discussed. Pinecone's own multitenancy guide works the example. With 100 tenants of 1 GB each, querying one tenant's namespace costs 1 read unit. By contrast, the same query against a single large namespace with metadata filtering costs 100 read units, because it scans all data regardless of filters.

A hundredfold cost difference on identical data, decided by a schema choice made in week one. If your workload has a natural partition key, tenant, workspace, project or document set, using it as a namespace is the single highest-return decision available on this platform.

The wider lesson generalises past this one vendor. Usage meters in AI infrastructure tend to bill a proxy for work rather than the work itself, and the proxy is often something you control. That pattern shows up across the category, and it is the same confusion documented in the breakdown of how credits and tokens obscure what you are actually buying.

Where pgvector actually runs out

The common claim is that pgvector fails above some vector count. That framing is wrong and it sends teams shopping too early.

pgvector fails when the index stops fitting in memory. Vector count is only a proxy for that, and a bad one, because the width of your embedding matters as much as the number of rows.

The index build is a memory problem before it is a query problem

pgvector's documentation is direct about this. When the graph outgrows the configured budget, the extension emits a notice that the HNSW graph no longer fits into maintenance_work_mem and that building will take significantly more time. The build then falls back to on-disk construction.

Most teams meet this at exactly the wrong moment, during a production reindex, with no runbook. The fix is not a different database. It is setting maintenance_work_mem before the build, raising max_parallel_maintenance_workers, and knowing in advance how large the graph will be.

Quantisation moves the ceiling further than a bigger instance does. The pgvector types make the trade explicit: full precision at 4 bytes per dimension, half precision at 2, and binary at one eighth of a byte.

Filtered search is the part that still needs care

Combining a vector search with a WHERE clause used to be pgvector's clearest weakness. The filter was applied after the approximate index had already chosen its candidates. Version 0.8.0 added iterative index scans, which keep pulling candidates until the filter is satisfied.

That helps, and it does not make the problem disappear. A March 2026 preprint studied filter-agnostic vector search inside a production PostgreSQL-compatible system. It found that performance is driven by system-level overheads such as page access and data retrieval, not by distance computation alone. The same paper reports that graph-based methods generated prohibitive numbers of filter checks, where clustering-based indexes did better. It is a preprint and has not been peer reviewed, which is worth saying alongside the finding.

The practical reading is that filtered vector search is a workload characteristic, not a product feature. Test it with your real selectivity before you decide anything. If you have not built a repeatable way to measure retrieval quality yet, that is the prerequisite, and the guide to standing up an evaluation suite covers the shape of it.

What the dedicated stores buy you that Postgres does not

Tenant scale is the clearest answer, and it is not close.

Weaviate documents shard architecture supporting 50,000 or more active shards per node, and around 1 million concurrently active tenants across roughly 20 nodes. A documented 9 node test cluster holds about 170,000 tenants. It also offloads inactive tenants to object storage, so dormant customers stop consuming memory.

Building the equivalent in Postgres means partitioned tables, per-tenant indexes and a cold storage tier you write and operate yourself. That is real work, and it is the point at which the build-versus-buy calculation genuinely flips. The same reasoning applies across the AI tooling stack and is worked through in the analysis of when building beats buying.

The second thing you are buying is not having to think about resharding. Pinecone and Weaviate both scale storage without you sizing an instance. If your team has no one who wants to own Postgres memory tuning, that is a legitimate reason to pay. Price it as a salary decision rather than an infrastructure one.

What you are not buying is retrieval quality. At matched recall, all three return comparable results, because they are running variants of the same algorithm. The difference is what it costs you in money and effort to reach that recall level at your scale.

What the latency benchmarks do and do not show

The benchmark literature in this category is thin and almost entirely produced by vendors. That is the honest state of the evidence, and it should lower your confidence in every latency number you have read, including the ones quoted here.

The most quoted result is a vendor benchmark from June 2024

Timescale, now Tiger Data, published a comparison of Postgres with pgvector and pgvectorscale against Pinecone. At 99% recall it reported 28 times lower p95 latency and 16 times higher throughput than Pinecone's storage optimised index, at about 25% of the monthly cost. Against Pinecone's performance optimised index at 90% recall, the same post reported a far narrower 1.4 times latency advantage.

Three things about that result deserve stating. It was run by a company selling one of the two products. It used a fork of the benchmarking tool rather than the tool as published. And it is now over two years old, against a serverless product that has been repriced since.

I would not make a purchasing decision on it. I would use it for the narrower claim it supports well, which is that Postgres is in the same performance class, and then run the comparison on your own data. The gap between a benchmark and a production readiness decision is covered in the checklist for moving an AI system from pilot to production.

One more framing correction. Recall is a setting, not a property of a product. Every one of these systems exposes a knob that trades accuracy for speed, and a benchmark that compares two systems at different recall levels is comparing nothing. Fix recall first, then measure latency.

A decision rule, and the cases where it breaks

Here is the rule I would apply, followed by the two situations where it gives the wrong answer.

Where this comparison is weakest

Four things in this post would not survive contact with a rigorous reviewer, and you should know which four.

Every cost figure is modelled, not billed

Nothing above came from an invoice. The numbers are published list rates multiplied by stated assumptions, and real bills diverge for ordinary reasons: committed use discounts, regional pricing, write volume, egress, and the "from" qualifier on Weaviate's dimension rates.

Treat the table as a way to see the shape of each pricing model, not as a quote. The ratio between columns is the durable finding. The absolute values are not, and they will be stale within two quarters. That is the same discipline that applies to any infrastructure line inside a gross margin calculation, which is the subject of the piece on what actually sits in AI cost of goods sold.

Engineering time is the missing column

The pgvector column looks better than it is, because a Postgres instance does not tune itself. Someone sets maintenance_work_mem, chooses m and ef_construction, decides on quantisation, monitors index bloat and owns the reindex. That person costs more per month than any row in the table.

I have left it out because I cannot source a defensible figure for it, not because it is small. If you are choosing between these options, put a number on that column yourself before you read the others.

The related gap is that this post treats retrieval as the whole system. It is not. Embedding generation, chunking strategy and re-ranking usually move answer quality more than index choice does. They also carry their own recurring cost, which is where the analysis of inference cost pressure on margins picks up.

Frequently asked questions

How to settle this in one afternoon

Do not start with a benchmark. Start with two numbers you can compute in a spreadsheet in ten minutes.

First, multiply your record count by 4 times your embedding width, add 8 bytes per row, and double the result. That is your approximate memory target for a resident HNSW index in Postgres. Compare it against the memory of the instance you already run. If it fits inside the next compute tier up, price that tier and stop reading vendor comparisons.

Second, if it does not fit, write down whether your data has a natural partition key before you talk to anyone. That answer, not latency, decides whether Pinecone's read meter works for you or against you by a factor of about 100. Take it into the sales call and ask both vendors to quote against it in writing.

Related reading