pgvector vs Pinecone for AI SaaS (2026)

The moment your AI feature has to answer questions about a customer's own documents, you need somewhere to keep embeddings, and every tutorial gives a different answer. Pinecone's quickstart takes five minutes, Supabase says you already have a vector database, and someone has told you Postgres "doesn't scale". Pick wrong and you either run a second database you didn't need, or rebuild retrieval six months after launch.

Should an AI SaaS use pgvector or a dedicated vector database?

Use pgvector inside the Postgres you already run: for almost every AI SaaS MVP it's the cheapest and simplest home for embeddings, and they inherit your existing tenant isolation. Move to a dedicated vector database such as Pinecone when the vector index outgrows your database's memory, vector work starts slowing your app, or you need features Postgres won't give you.

The decision is less about search quality than founders assume. At MVP scale both return good nearest neighbours, and answer quality depends far more on how you chunk documents and which embedding model you use. The real question is where your data lives. pgvector keeps embeddings one join away from the documents, users and permissions they belong to. A dedicated store scales independently, and in exchange hands you a second copy of your data to sync.

What are embeddings, and what does RAG need from a vector store?

An embedding is a list of numbers (1,536 of them for OpenAI's text-embedding-3-small) that a model produces from a piece of text. Texts with similar meaning get numerically similar lists, so "cancel my subscription" and "how do I stop being billed?" land close together despite sharing no keywords. Vector search finds the stored embeddings nearest a query's; at scale it uses an approximate index that trades a sliver of accuracy for speed.

Retrieval-augmented generation (RAG) is the pattern behind most "chat with your documents" features: split documents into chunks, embed each one, then at question time fetch the most relevant chunks and hand them to the LLM as context. From a vector store, RAG needs fast top-k search, filtering (this customer, this project, documents this user may see), reliable writes as documents change, and ideally keyword search alongside vectors, because exact terms like product codes and error messages are where pure vector search is weakest.

Most of that is what your main database already does well, which is the whole case for pgvector. Which AI features deserve a retrieval pipeline at all is covered in when to add AI features to your SaaS MVP.

How do pgvector, Pinecone and the alternatives compare?

Prices are as of October 2026, in the currency each vendor bills. Vendors change pricing often, so check the Pinecone pricing page and its peers before you commit.

pgvector is an open-source Postgres extension: one CREATE EXTENSION, a new column type and two approximate index types. HNSW gives the better speed-to-recall trade-off; IVFFlat builds faster and uses less memory. Supabase, Neon and Amazon RDS all support it, and we compare those three hosts in Neon vs Supabase vs AWS RDS. The prize is that a vector query is just SQL: join chunks to documents, filter by permissions, and delete a document's embeddings in the same transaction as the document. Nothing to reconcile.

Pinecone is the best-known managed vector database. New indexes are serverless, so you size nothing and pay for what you read, write and store, and it puts hybrid search, reranking and hosted embedding models behind one API. The cost is architectural: a second system holding a copy of your data, kept in step with Postgres through every edit and deletion.

Qdrant is open source under Apache 2.0 with a managed cloud and strong filtering, the credible pick when self-hosting matters. turbopuffer keeps data on object storage with an SSD cache: big corpora are cheap to hold, but the first query against a cold namespace is noticeably slower.

How much does a vector database cost on Supabase?

pgvector costs nothing extra on Supabase. It's a free extension, so you pay for the disk and memory your embeddings occupy on the plan you already have. pgvector stores each vector in four bytes per dimension plus eight, so a 1,536-dimension embedding is about 6 KB, and 100,000 chunks is roughly 615 MB before the text or index. That overflows the Free plan's 500 MB database, but on Pro 8 GB of disk is included and extra is $0.125/GB, so storage stays trivial.

Memory is the real line item, because HNSW trades memory for speed. Supabase's own pgvector compute benchmarks (HNSW, 1,536 dimensions, 0.99 accuracy) pair about 15,000 vectors with the 1 GB Micro instance and a million with the 32 GB 2XL, at ~$410/month. Two cheap levers help: store halfvec instead of vector to halve the bytes, or request fewer dimensions from the embedding model. Check recall on your own queries after either.

On Pinecone, storage at $0.33/GB-month barely registers; you mostly pay for reads and writes. So at MVP scale pgvector is effectively free, while at a million vectors with modest traffic a usage-priced store can undercut upsizing your whole database. The full plan maths is in Supabase pricing explained.

Supabase also offers Vector Buckets, an S3-backed vector store in public alpha for Pro projects and above, free under fair use during the alpha with egress billed. We'd wait for general availability before building on it.

What do the embeddings themselves cost?

Far less than the LLM calls that use them. Embedding models are priced per input token, and OpenAI's guide estimates around 62,500 pages per dollar for text-embedding-3-small. Generation is where AI budgets actually go, compared in OpenAI vs Anthropic for SaaS and, for cheaper open-weight models, in open-source LLMs vs OpenAI & Anthropic.

Two decisions matter more than the price. Switching embedding model means re-embedding everything, because different models' vectors aren't comparable. And pgvector indexes vector up to 2,000 dimensions and halfvec up to 4,000, so text-embedding-3-large, at 3,072 dimensions, needs halfvec or a shorter output via OpenAI's dimensions parameter.

How do you keep each customer's embeddings isolated?

With pgvector, the same way you isolate every other table: a tenant_id on each chunk plus Postgres Row-Level Security, so retrieval can't return another customer's documents even when code forgets to filter. In Pinecone, the equivalent is a namespace per tenant.

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE chunks (
  id bigserial PRIMARY KEY,
  tenant_id uuid NOT NULL,
  content text NOT NULL,
  embedding vector(1536) NOT NULL
);
CREATE INDEX ON chunks (tenant_id);
CREATE INDEX ON chunks USING hnsw (embedding vector_cosine_ops);

SET LOCAL hnsw.iterative_scan = strict_order;
SELECT id, content FROM chunks
WHERE tenant_id = $1
ORDER BY embedding <=> $2 LIMIT 5;

Enable RLS on chunks and run the query inside the transaction that sets the current tenant, as in our multi-tenant SaaS architecture guide; the explicit WHERE is then belt and braces.

One subtlety is specific to vectors. An approximate index is shared by every tenant and filters after searching, so a small tenant can get fewer results than the LIMIT asks for. pgvector's docs give the example of a filter matching 10% of rows returning about four results on average with default HNSW settings. Version 0.8 added iterative index scans, which keep searching until enough rows match: that's the SET LOCAL line. The docs also note that an ordinary index on the filter column (exact search) works well when the filter matches a small fraction of rows, which is one tenant among many. For your largest customers, they recommend list partitioning by tenant, so no one else's vectors affect their recall or speed.

Pinecone recommends one namespace per tenant: namespaces are stored separately, queries are billed by the namespace's size rather than the whole index's, and offboarding a customer means deleting their namespace. The catch is that isolation depends on your code choosing the right namespace on every call. The check lives in your application, not the database.

When should you move off pgvector?

When vectors start costing your main database something (memory, latency or attention) that a separate store wouldn't. The signals we watch for:

• The index no longer fits comfortably in RAM, and you'd be upsizing the whole database purely for vectors.
• Vector work hurts the app. Bulk re-embedding or HNSW builds, slow on large tables, start dragging down the queries your dashboard depends on.
• The corpus is heading for tens of millions of vectors.
• Query traffic is spiky in a way you don't want to provision Postgres for.
• You need features you'd otherwise build: managed hybrid search with reranking, hosted embeddings, or namespaces at very large tenant counts.

A benchmark blog post or an investor asking about your vector database is not a signal.

Keep the exit cheap from day one. Postgres stays the source of truth for chunk text and metadata, retrieval sits behind one function in your codebase, and each row records which embedding model produced it. Moving to Pinecone is then a backfill into per-tenant namespaces, a period of dual writes and a comparison of results before switching reads: a project, not a rewrite. The painful version is similarity queries scattered through the codebase.

Our default: pgvector in the same Postgres

For the AI SaaS products we build, embeddings live in pgvector in the same Postgres as everything else, usually Supabase, alongside Next.js, Clerk, Stripe and Resend on Vercel. It's the retrieval layer in our SaaS MVP tech stack: one database, one backup, one set of RLS policies, and retrieval that joins straight to documents and permissions. Ingestion runs as background jobs, so embedding a long PDF never hits a serverless timeout.

We start with HNSW on cosine distance, tenant_id and RLS on every chunk, iterative scans on, and the embedding model recorded per row. We deviate when the signals above appear, or when a product is retrieval-first at scale from day one. Then it's usually Pinecone for a hands-off managed service, turbopuffer for huge corpora spread thin across tenants, or Qdrant when the client must self-host. Postgres remains the source of truth either way.

What we accept is a database that grows with the corpus and some index tuning a managed service would do for us: a fair price for one fewer system.

Frequently asked questions

Is pgvector production-ready?

Yes. It's a mature, actively maintained extension offered by Supabase, Neon and Amazon RDS, among others. HNSW indexing arrived in version 0.5 in 2023, half-precision and sparse vectors in 0.7, and iterative scans for filtered queries in 0.8. Its limits are a database's: RAM sizing, slow index builds on very large tables, and tuning you do yourself.

Does Supabase charge extra for vector search?

No. pgvector is a free extension, so vectors cost only the disk and compute they use on your normal plan. Disk is cheap; memory is what grows. If your corpus is large, budget for a bigger compute size rather than a new product. Vector Buckets, the separate alpha product, are free under fair use for now.

Can pgvector do hybrid keyword and vector search?

Yes, by combining pgvector with Postgres full-text search in one SQL query. Rank by full-text relevance and by vector distance, then merge the two lists with reciprocal rank fusion. Pinecone, Qdrant and turbopuffer build this in, which is convenient but not, on its own, a reason to add a second database.

Want an AI feature built on the right retrieval stack?

Where your embeddings live is a small decision with long consequences for cost, tenant isolation and how fast you ship. If you want retrieval scoped around your actual documents, customers and traffic, book a free scoping call. We'll recommend the setup and quote the build fixed-price, so you know the cost before committing.