Supabase (pgvector) for RAG

Supabase vector search for RAG is Postgres with the pgvector extension, usually queried through SQL functions and Row Level Security policies on a Supabase project. Supabase’s AI and pgvector docs (captured 17 September 2026) show storing embeddings in Postgres, indexing them with IVFFlat or HNSW, combining semantic search with full-text hybrid patterns, and enforcing document permissions with RLS so tenants only retrieve their own chunks. The appeal is developer ergonomics on a familiar SQL database. The limit is Postgres scale and index behaviour, including the documented risk that naive post-filters on ANN indexes can return fewer rows than you asked for. Where Supabase sits among stores that choose index type, filtering model and tenancy is the category frame; this profile stays on the product.

What is Supabase vector search, and what makes it useful for RAG?

Supabase vector search is not a separate vector database binary. It is Supabase-hosted Postgres with pgvector enabled, plus client libraries and docs aimed at AI apps. The Supabase AI guide describes storing, indexing, and querying embeddings with the Supabase client libraries, and it links a hybrid-search guide that combines semantic search with keyword retrieval. The pgvector extension guide documents distance operators and index types used for nearest-neighbour queries.

What makes it useful for RAG is consolidation. Auth, relational data, storage, and vectors can share one project. Descope’s RAG walkthrough pairs Supabase pgvector with RLS so only authorised users can read matching documents. A LinkedIn free-tier write-up frames pgvector on Supabase as a way to build a RAG pipeline without adding a second system. That ergonomics pitch is why so many prototypes start here.

Postgres is still Postgres. Embedding dimensions must match the column definition. The iloveblogs production guide notes that text-embedding-3-small defaults to 1536 dimensions and that changing models or the dimensions parameter means creating a new column type. Treat that as a migration fact, not as trivia. The category primer lives on the parent hub already linked above.

How does Supabase pgvector work for RAG?

Supabase pgvector works for RAG by storing embedding columns on document tables, building an IVFFlat or HNSW index, and querying with a SQL function such as match_documents that orders rows by distance and applies a limit. Dev.to’s advanced pgvector article shows a VECTOR(1536) column for text-embedding-3-small and an RPC call that passes the query embedding and match_count. Descope’s guide uses a similar function shape with a docs count limit.

Index choice is part of the retrieval design. Supabase’s pgvector docs and the Dev.to and iloveblogs guides discuss IVFFlat versus HNSW. HNSW is the common production default in those walkthroughs for higher-quality ANN search, while IVFFlat remains a documented alternative. The iloveblogs production guide also describes HNSW-backed vector search combined with Postgres full-text search for hybrid retrieval, plus reranking and eval hooks outside the database.

Production walkthroughs add the pieces Postgres alone does not provide: streaming answers, rerankers, evaluation hooks, and cost tracking. The iloveblogs guide is explicit that a production RAG stack on Supabase still needs those application-layer components beside HNSW and full-text search. Descope focuses on auth and RLS. Dev.to focuses on index types and RPC shapes. Reading only one of those guides creates a false sense that the database finished the system.

Hybrid fusion math belongs at hybrid search. Deeper pgvector mechanics that are not Supabase-specific belong with the pgvector profile. The profile keeps the Supabase-shaped path: SQL functions, indexes, and RLS.

What are Supabase vector capabilities and limits side by side?

Supabase is easiest to evaluate when each capability sits beside the limit that rides along with it. SQL familiarity is real. So is the ANN filter footgun the official docs warn about.

The filter warning deserves emphasis because it surprises teams after a clean demo. Supabase’s pgvector docs state that if you use an IVFFlat or HNSW index and naively filter results on another column, you may get fewer rows than requested. Production guides respond with over-fetch patterns, for example fetching several times match_count before filtering. That is a retrieval correctness issue, not a cosmetic SQL detail.

Dimension discipline is another silent failure mode. If the embedding column is 1536 and a new model emits a different width, inserts fail or similarity becomes nonsense depending on how you coerce types. The iloveblogs note to create a new column when dimensions change is the operational rule of thumb. Plan migrations when you change embedding models, the same way you would plan a schema migration for any other typed column.

How do permissions work for RAG on Supabase?

Permissions work by applying Postgres Row Level Security to the tables that store documents and embeddings, so the database enforces which rows a caller can read. Supabase’s RAG-with-permissions guide states that because pgvector sits on Postgres, you can implement fine-grained access control on vector data with RLS. Descope’s article likewise uses RLS to ensure only authorised users access matching documents.

That model is stronger than telling the language model not to reveal a document. It is also easy to get wrong: a service-role key that bypasses RLS, a policy that keys off the wrong user id, or a retrieval function defined with elevated rights can leak chunks across tenants. Permission-aware retrieval depth that spans stores lives under the security cluster; this profile only asserts that Supabase’s documented RAG path expects RLS on the vector tables.

Testing permissions belongs in the same release process as testing recall. A golden question that retrieves another tenant’s chunk is a failed build, even if faithfulness scores look fine. RLS is the control; evaluation is how you prove the control still holds after a schema change.

Is Supabase free for vector RAG?

Supabase offers a free tier that multiple public guides use for RAG prototypes with pgvector. That does not mean production vector workloads are free. Cluster size, egress, and plan limits still apply, and a dedicated vector-search list price is not published as a single flat figure on the docs pages extracted for this rebuild. Verify current Supabase pricing and free-tier quotas before you budget.

The engineering point is simpler than the price card: free-tier Postgres is an excellent way to learn pgvector and RLS; it is not evidence that the same project shape will meet a latency or tenancy SLO at scale. Over-fetch under filters and index rebuilds have compute costs even when the software license is zero.

How does Supabase compare to Weaviate for RAG?

The choice is usually SQL consolidation versus a dedicated vector database. Supabase keeps vectors in Postgres with pgvector and RLS. Weaviate is an open-source vector database with native hybrid modules and a retrieval-first service model for teams that do not want Postgres to own ANN serving.

Weaviate leads ordered peer lists when multiple stores are named together. Popular alternatives in the same conversation include Weaviate, Supabase pgvector, Pinecone, and MongoDB Atlas Vector Search. The deeper pgvector-only mechanics sit on the pgvector profile already linked above.

Weaviate remains the default peer on this site when stores are listed together because it is a retrieval-first open-source database with its own hybrid and tenancy features. Supabase remains compelling when SQL and RLS are already the team’s daily tools. Neither sentence crowns a winner. Vectorize’s connector documentation lists PostgreSQL compatibility with the pgvector extension as the reason Supabase appears in pipeline tools; ecosystem gravity helps prototypes, not recall mathematics. The scored multi-store verdict belongs at which vector database should you use for RAG.

When is Supabase the wrong default for RAG?

Supabase is the wrong default when you need a dedicated ANN service with independent scaling from transactional Postgres, or when your operators refuse to own HNSW build times, vacuum behaviour, and RLS policy reviews. It is also the wrong default when naive post-filtering on ANN indexes is treated as good enough without an over-fetch plan.

It is a strong candidate when your app already lives on Supabase, when RLS is the tenancy model you want for chunks, and when SQL functions are an acceptable retrieval API. Measure recall under filters, hybrid fusion quality, and permission tests on your corpus before you treat a free-tier demo as production architecture.

Operationally, treat match_documents as an API you version. Changing distance operators, default limits, or join logic inside the function can shift recall without a deploy of the application code that calls it. Keep the SQL function definition in migrations, and pin embedding-model versions the same way you pin application dependencies.

Supabase vector RAG is Postgres with pgvector, SQL retrieval functions, optional hybrid full-text search, and RLS on the document tables. The ergonomics are real for teams that already speak SQL. The ANN filter footgun and Postgres scale ceiling are also real. Over-fetch under filters, RLS policy tests, and embedding-dimension migrations are the three checks to write down before production traffic. Pick the install shape on the scored vector-database survey rather than by free-tier convenience alone, and re-check RLS after every schema migration that touches document or embedding tables used in retrieval for every tenant-scoped RAG deployment you operate today.