Vector Databases for SaaS in 2026: pgvector, Pinecone, Weaviate

Every SaaS product that puts a search box over its own documents hits the same fork within a week. Embeddings work. The demo pulls back the right paragraph. Then someone asks where the vectors are going to live, and that answer decides your infrastructure bill and how many separate systems you have to reason about when retrieval goes sideways on a Sunday night.

The comparison posts answer it with a feature matrix and a recommendation shaped like "it depends on your scale." Scale is the least interesting variable in the decision. For a multi-tenant product the deciding question is what happens when you add WHERE tenant_id = $1 to the query, and almost nobody benchmarks that, because published vector benchmarks run unfiltered.

Three options are worth real consideration. pgvector, which rides along inside a database you already pay for. Pinecone, which is managed and metered by the read. Weaviate, which is the only one of the three whose storage model was designed around tenants in the first place.

Do you need a dedicated vector database for SaaS in 2026?

Most SaaS products under roughly five million embeddings do not, because Postgres with pgvector keeps vectors inside the same transaction boundary as the rows they describe.

Ivan Cernja's March 2026 comparison on Encore puts the practical crossover near five million vectors, with pgvector HNSW returning in 5 to 20 milliseconds at 95%-plus recall below that mark. Under a million vectors both a dedicated service and an extension answer in single-digit to low-double-digit milliseconds, and the gap between them disappears into network time before it ever reaches a user.

Staying in Postgres does not buy you speed. It buys you the ability to write one query that joins an embedding search against your permissions table and your soft-delete flag, inside a transaction, with one backup and one restore path. Split the vectors into a separate service and each of those becomes an application-level join across two systems with two different consistency stories, plus a reconciliation job for the day they disagree.

What does your retrieval query actually look like in production? Not the demo version. The one carrying the tenant scope and the role check that decides whether this user is allowed to see the chunk you are about to paste into a prompt.

Tenant filtering is the question, not latency

The vector store decision for a multi-tenant SaaS is a filtering decision, and the benchmarks you have read ran unfiltered.

Here is the mechanic that matters. In pgvector, metadata predicates are applied after the ANN index scan, so a filtered query traverses a global HNSW graph built over every tenant's vectors and then discards the rows that did not match. Filtered HNSW, or per-tenant segment indexes, is an open feature request rather than a shipped capability. The documented workarounds are partial indexes per filter value, table partitioning, or turning up hnsw.ef_search and paying for the extra traversal.

pgvector 0.8.0 softened the worst symptom with iterative index scans, which keep pulling candidates until enough rows survive the WHERE clause instead of returning four results when your application asked for ten. That fixes the visible bug. It does not make the index filter-aware, and on a tenant holding half a percent of your total vectors you are still walking a graph built for the other 99.5%.

Weaviate solved the same problem at the storage layer. Each shard holds data for a single tenant, so a tenant-scoped query searches a graph containing only that tenant's vectors and nothing else. Weaviate's own docs put roughly 18,000 to 19,000 active tenants on a node in a nine-node test, and describe supporting a million concurrently active tenants across about twenty nodes. Tenants nobody is querying go INACTIVE on local disk, or OFFLOADED to S3, which is how the active count stays under the Linux per-process open file limit that would otherwise cap it. Pinecone takes a middle path with namespaces, which partition an index without giving each partition its own graph.

I have not run pgvector under a clinic caseload, so take the architectural claim rather than a benchmark from me here. Callidus, the multi-tenant clinic SaaS I built for UK aesthetic clinics between February and April 2026, is React on Firebase, and its isolation lives in Firestore rules and shared role helpers rather than in any index. The transferable lesson is narrow and it holds: every read path carries tenant identity, and a query that can express a tenant scope but cannot enforce it at the storage layer is a query somebody eventually gets wrong. On Postgres that enforcement is row-level security, the way the React and Supabase RLS stack applies it, and it works on a vector column exactly as it works on anything else. The policy gets checked. The index simply does not know about it.

What pgvector, Pinecone, and Weaviate actually cost

Pricing across the three is not comparable on one axis, because one is an extension you already own, one bills per operation, and one bills for nodes you run or a cloud tier you buy.

Pinecone's figures come from its own pricing page, where the free tier stops at 2 GB of storage, 2 million write units, 1 million read units and 1 GB of egress per month. Those free-tier ceilings are the ones that mislead teams. A RAG feature in beta fits inside them comfortably.

Write units are where the surprise usually lands. The first invoice that makes you look twice arrives after a bulk import: a customer drags three years of PDFs into your uploader on a Thursday afternoon, every document gets chunked and embedded, and a quarter of a million write units clear in about ninety minutes. Nothing broke. Your product analytics show one successful import. The line item shows something else entirely.

The memory math nobody runs first

Real HNSW deployments land near 20 to 25 kilobytes per vector at 1,536 dimensions once graph metadata is counted. Five million vectors is therefore 100 to 125 GB of RAM if you want the index resident. Price that instance before you call pgvector free.

How do I choose a vector store for a RAG feature?

Start in Postgres, instrument the filtered query, and move only when a measured number breaks: index memory or p99 under the tenant filter.

1. Count your vectors, then count them again at twelve months out. Chunks per document, times documents per tenant, times tenants, plus whatever growth you are selling against. If that number stays under roughly five million, the rest of this list is a formality and you should be writing product code instead.
2. Write the filtered query before you benchmark anything. Tenant scope and permission check attached, exactly as it will run. That is the query whose p99 decides your architecture, not the unfiltered nearest-neighbour lookup every vendor benchmark publishes.
3. Size the index in RAM before you price a vendor. Vector count multiplied by 20 to 25 KB, compared against your current instance and the next tier up. Do this in a spreadsheet, in five minutes, before anyone opens a pricing page.
4. Check your dimension count against the index ceiling. HNSW and IVFFlat cap at 2,000 dimensions on the standard vector type because of the 8 KB Postgres page size, and halfvec raises that to 4,000. A 3,072-dimension embedding model forces this decision quietly, usually at the worst moment.
5. Decide whether re-embedding is a product event. If editing a document re-embeds it, your write volume tracks user behaviour rather than corpus size, and metered write pricing becomes a variable cost you do not control.
6. Only then compare vendors.

If you are picking infrastructure from scratch rather than retrofitting retrieval onto something already running, my opinionated SaaS MVP stack covers what pairs cleanly with what, and Supabase ships pgvector as a dashboard toggle, which removes the extension-install step that stops some teams from ever trying it. Before any of that, settle which AI features are worth adding to a business product at all, because semantic search over your own documentation is rarely the feature customers ask for first.

Hybrid search beats whichever store you picked

Combining BM25 keyword retrieval with dense vector search, fused by reciprocal rank fusion, outperforms either method alone by a wider margin than the gap between most vector stores.

On the WANDS e-commerce dataset, Doug Turnbull measured basic RRF hybrid at NDCG 0.7068 against 0.6983 for BM25 alone and 0.6953 for pure vector search in March 2025, with a tuned hybrid reaching 0.7497, about a 7.4% lift. One dataset, furniture queries, so treat the exact number as directional rather than a promise.

Actually — that undersells why it matters for a SaaS. Your users search for things dense vectors are structurally bad at. Invoice numbers. A patient surname. A SKU with a hyphen in it. Semantic retrieval returns something adjacent and confidently wrong, and the user has no way to tell the difference from the interface. Postgres gives you tsvector full-text search sitting in the same database as your vector column, so hybrid is a second query and a fusion function rather than a second vendor and a second bill. Weaviate ships hybrid natively. Pinecone supports sparse-dense vectors. Whichever store you land on, budget for hybrid on day one instead of discovering it through the first support ticket about a missing exact match.

Pin the version, then read the changelog

pgvector shipped four patch releases in six weeks this summer, and one of them fixed index corruption.

Between 17 June and 29 July 2026, pgvector moved from 0.8.3 to 0.8.6. 0.8.3 fixed index corruption during HNSW vacuuming. 0.8.4 stopped IVFFlat builds from allocating past maintenance_work_mem. 0.8.6 closed a buffer overflow in IVFFlat construction on 32-bit builds. If you run managed Postgres that pins extension versions to whatever shipped with your major version, find out which pgvector you are actually on before you assume the vacuum path is safe.

That upgrade cadence is the tax nobody puts in the comparison table. A managed service absorbs it on your behalf, and that absorption is a real part of what the read units are buying. Choosing the extension means owning the release cadence of a young extension inside your most critical database, forever.

Open psql against staging tonight, run your retrieval query with the tenant filter attached, and put EXPLAIN (ANALYZE, BUFFERS) in front of it. Look at how many rows the index scan returned before the filter and how many survived it. That ratio is most of the decision, and it takes about four minutes to get.

Then answer the question no vendor comparison table can: at your real tenant size distribution, how much of every search you serve is a graph traversal across data the user is not allowed to see?