Supabase for AI: pgvector, RLS, and Production RAG Infrastructure

Key takeaways

1. One database, not two: pgvector adds vector similarity search to Postgres, so embeddings live beside the relational data they describe.
2. RLS enforces access control at the data layer: a compromised application server cannot retrieve rows a policy denies.
3. Metadata filtering happens in SQL, not in application logic: combine vector similarity with a `WHERE` clause on tenant, permission, or freshness columns in one query.
4. Edge functions handle embedding close to the write: generate an embedding on document insert instead of a separate batch job.
5. This is an infrastructure choice, not a RAG-quality guarantee: chunking and retrieval tuning still determine answer accuracy.

What does a pgvector setup look like?

pgvector is a Postgres extension that adds a vector column type and similarity-search operators. A minimal RAG table stores the chunk text, its embedding, and the metadata needed for access control and freshness checks.

create extension if not exists vector;

create table document_chunks (
  id uuid primary key default gen_random_uuid(),
  tenant_id uuid not null references tenants(id),
  document_id uuid not null references documents(id),
  content text not null,
  embedding vector(1536),
  source_url text,
  last_verified_at timestamptz not null default now()
);

create index on document_chunks
  using ivfflat (embedding vector_cosine_ops) with (lists = 100);

The index type and list count affect query speed versus recall — Supabase's own AI & Vectors documentation covers index tuning in more depth than fits here; the defaults are a reasonable starting point, not a final answer for high-volume production traffic.

How does row-level security apply to a RAG pipeline?

Without RLS, "only return chunks this user can see" is application logic — a filter added to a query, which means it can be forgotten in one code path and not another. With RLS, the policy is attached to the table itself and Postgres enforces it on every query, regardless of which application code issued it.

alter table document_chunks enable row level security;

create policy tenant_isolation on document_chunks
  for select
  using (tenant_id = (auth.jwt() ->> 'tenant_id')::uuid);

For multi-tenant RAG — several customers' documents in one database — this closes the most common and most dangerous failure mode: a retrieval query that accidentally returns another tenant's data because an application-level filter was missing on one endpoint. The same pattern extends to document-level permissions, not just tenant isolation, by joining against a permissions table inside the policy.

Where do realtime and edge functions fit?

Two Supabase features are useful in a RAG pipeline beyond storage. Edge Functions can run the embedding step at the point of ingestion — a document is inserted, a database webhook triggers an Edge Function, the function calls an embedding model and writes the vector back — so ingestion and embedding stay in one event-driven path instead of a separate batch job that can drift out of sync with the source documents. Realtime subscriptions let a frontend reflect ingestion status (queued, embedding, indexed) without polling, which matters for any RAG admin UI where documents are uploaded and processed asynchronously.

What should be in place before this goes to production?