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

Your prototype search works. The demo pulls back the right paragraph, and now someone asks where the vectors should live. Before you compare vendors, write down the exact query your product will run in production, including the tenant filter and the permission check, because that query decides the answer more than raw scale does.

Most comparison posts answer with a feature matrix and "it depends on your scale." For a multi-tenant product the deciding question is what the index does when you add WHERE tenant_id = $1, and published benchmarks mostly run unfiltered. Three options are worth real consideration: pgvector inside a Postgres you already pay for, Pinecone as a managed service metered by usage, and Weaviate, whose storage model is built around tenants.

Everything below was checked against pgvector's repository and the Pinecone and Weaviate documentation on 30 September 2026. Where a number comes from a benchmark I could not verify on a vendor page, I removed it.

Do you need a dedicated vector database for SaaS?

Often not, because Postgres with pgvector keeps vectors in the same transaction, backup and permission model as the rows they describe, and that consistency is worth more than a small speed difference.

Staying in Postgres lets you write one query that joins an embedding search against your permissions table and your soft-delete flag, with one backup and one restore path. Split the vectors into a separate service and each of those joins becomes application code across two systems with two consistency stories, plus a reconciliation job for the day they disagree. I can't give you a crossover vector count from a primary source, and published crossover figures come from benchmarks on someone else's hardware. Measure your own.

Storage is the part you can calculate. The pgvector README says each vector takes 4 * dimensions + 8 bytes, so a 1,536-dimension embedding is about 6 KB before any index. Five million of them is roughly 30 GB of raw vectors, and the README notes that HNSW indexes build much faster when the graph fits in maintenance_work_mem and perform best in memory. Size the instance for the index, not only the table.

pgvector vs Pinecone vs Weaviate: what changes when you filter by tenant?

Tenant filtering is where the three diverge: pgvector filters after the index scan, Pinecone recommends a namespace per tenant, and Weaviate gives each tenant its own shard.

How does pgvector handle a WHERE clause?

The pgvector README states that with approximate indexes, filtering is applied after the index is scanned. With the default hnsw.ef_search of 40, a condition that matches 10% of rows returns only 4 results on average. Two documented mitigations exist. Version 0.8.0 added iterative index scans, which keep scanning until enough rows survive the filter, in strict_order or relaxed_order modes. For filter columns with few distinct values the README suggests partial indexes, and for many values it suggests partitioning. Supabase's pgvector guide gives the same warning: naive filtering can return fewer rows than requested, and iterative search is the recommended fix.

None of this makes the index tenant-aware. On a tenant holding a tiny share of your vectors, you are still traversing a graph built over everyone's data. That suggests partitioning by tenant once tenants are large and few, which is a design choice you should test before you rely on it.

What does Weaviate do differently?

Weaviate's data concepts documentation says each shard holds data for a single tenant, so a tenant-scoped query searches only that tenant's vectors. The same page says you can have 50,000 or more active shards per node, and that 1M concurrently active tenants need about 20 nodes. A tested nine-node cluster reached roughly 170,000 active tenants in total. Tenants can be INACTIVE on local disk or OFFLOADED to S3, which keeps the active count below the Linux open-file limit per process. The cost is that you operate a cluster.

Where do Pinecone namespaces fit?

Pinecone's multitenancy guide recommends one namespace per tenant on a serverless index, and says each namespace is stored separately, which gives physical isolation between tenants. Its own example: querying a tenant's 1 GB namespace costs 1 read unit, while metadata filtering across a shared 100 GB namespace costs 100 read units because it scans all data regardless of filters. That is Pinecone describing its own billing, so treat it as a vendor claim, but the direction is clear: with Pinecone, isolation and cost are decided by how you lay out namespaces.

Callidus, the multi-tenant clinic SaaS I built for UK aesthetic clinics, is React on Firebase, so it doesn't use vectors and I can't offer a benchmark from it. The case study documents the transferable rule: everything lives under tenants/{tenantId}/, with tenantId and role carried in JWT claims. On Postgres the equivalent is row-level security, as in the React and Supabase RLS stack. Neither the pgvector README nor the Supabase page I checked covers RLS together with vector indexes, so test that a policy plus your index returns the rows you expect.

What do pgvector, Pinecone and Weaviate cost?

Pricing isn't comparable on one axis: pgvector rides on capacity you already pay for, Pinecone bills per operation with a monthly minimum, and Weaviate bills for nodes you run or a cloud tier.

Those Pinecone figures come from its pricing page, which also lists the free Starter tier at 2 GB of storage, 2M write units and 1M read units per month with 100 namespaces per index, against 100,000 on Standard. Weaviate's managed pricing wasn't part of this check, so I left it out of the table. Write units are where surprises land: if editing a document re-embeds it, your write volume follows user behavior and not corpus size, and a bulk import is a variable cost you don't control.

Which version of pgvector should you run?

Pin the version and read the changelog, because a young extension moves quickly inside your most critical database. The pgvector changelog shows four patch releases between 17 June and 29 July 2026. Version 0.8.3 removed a potential index-corruption risk with HNSW vacuuming, 0.8.4 fixed an HNSW vacuum error and made IVFFlat builds respect maintenance_work_mem, and 0.8.6 fixed a buffer overflow in IVFFlat construction on 32-bit systems. If your managed Postgres pins extension versions, find out which one you are on. A managed vector service absorbs that upkeep for you, and that is part of what its usage fees buy.

How should you choose a vector store for a RAG feature?

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

1. Count your vectors at twelve months out. Chunks per document, times documents per tenant, times tenants.
2. Write the filtered query before you benchmark anything, with tenant scope and permission check attached, exactly as it will run.
3. Size the index in RAM, using the 4 * dimensions + 8 bytes per vector figure plus graph overhead, before you open a pricing page.
4. Check your dimension count against the index ceiling. HNSW and IVFFlat index up to 2,000 dimensions on the vector type and 4,000 on halfvec, according to the README. A 3,072-dimension model forces the decision.
5. Decide whether re-embedding is a product event, because it turns metered write pricing into a variable cost.
6. Only then compare vendors on the queries you wrote in step 2.

Do you need hybrid search from day one?

Plan for it, because your users search for invoice numbers, surnames and SKUs, which dense vectors handle poorly. The pgvector README recommends combining vector search with Postgres full-text search, merged by Reciprocal Rank Fusion or a cross-encoder, so hybrid is a second query and a fusion function inside the same database. Weaviate's hybrid search documentation describes native BM25 plus vector search with relative score fusion as the default. Pinecone's hybrid guide describes a single sparse-dense index. I have not verified any relevance-gain percentage on a vendor page, so measure the lift on your own queries.

If you're picking infrastructure from scratch, my opinionated SaaS MVP stack covers what pairs with what, and Supabase lets you enable pgvector from its dashboard or with one SQL statement. Before any of that, settle which AI features are worth adding to a business product.

Open psql against staging, put EXPLAIN (ANALYZE, BUFFERS) in front of your retrieval query with the tenant filter attached, and compare how many rows the index scan returned with how many survived the filter. What is that ratio for your smallest tenant?