Why pgvector instead of a separate vector database?

pgvector keeps your embeddings in the same Postgres database as your application data, so you get joins, row-level security, transactions, and backups for free without operating a second system. For most apps under tens of millions of vectors this is simpler and cheaper than a dedicated vector DB. You can always migrate later if scale demands it, but starting in Postgres removes a whole moving part.

Which index should I use on the vector column?

For most workloads an HNSW index gives strong recall and fast queries; IVFFlat is lighter on memory but needs tuning of its list count and a representative sample to train. Build the index after you have loaded a meaningful amount of data so it reflects real distribution. Always pick the distance operator (cosine, inner product, or L2) that matches how your embedding model was trained.

How do Edge Functions keep my API key safe?

Edge Functions run on Supabase's servers, so they read your provider key from function secrets and the key never reaches the browser. The client calls your Edge Function, which calls the model and returns the result. This is the same principle as any backend — keep keys server-side — and Supabase secrets give you a managed place to store them per environment.

How does row-level security fit an AI app?

Add a user_id column to your vectors table and write RLS policies so each user can only read and search their own rows. Because the embeddings live in Postgres, the same policies that protect your other tables protect your vector search automatically. Without RLS, a similarity query could surface another tenant's private documents, so enable it before you store anything real.

How much storage and memory will my vectors need?

Each vector takes roughly four bytes per dimension, so a 1536-dimension embedding is about 6 KB before index overhead, and HNSW indexes add substantial memory on top. Storage and index memory scale linearly with row count and dimension. The planner below estimates total vector storage and approximate index memory from your row count, embedding dimension, and chosen index so you can size your Supabase plan.

How to Build an AI App with Supabase and pgvector

What you are building

This tutorial builds a full-stack AI app on a single Supabase project. You use Supabase Auth for users, Postgres with pgvector for embeddings, Edge Functions for the LLM and embedding calls, and Realtime to stream answers to the client. Everything — application data, vectors, and access control — lives in one database, so you get semantic search, joins, row-level security, and backups without operating a separate vector store. It is the leanest way to ship a RAG-style app that still scales to millions of vectors.

How it works

You enable Supabase Auth and run create extension vector, then create a table with a vector column sized to your embedding model, plus the source content and a user_id. An Edge Function handles writes: it reads your provider key from function secrets, embeds the text server-side, and inserts the row — the key never touches the browser. For reads, you add an HNSW (or IVFFlat) index on the vector column and an RPC that returns the nearest rows by cosine distance; row-level security policies keyed on user_id ensure a search only ever surfaces the caller’s own data. Those nearest rows become context for an LLM call, and the streamed answer is pushed to the client over Supabase Realtime so it appears incrementally.

Tips and the planner below

Enable RLS before you store anything real — without it, a similarity query can leak another tenant’s documents. Match the index distance operator to how your embedding model was trained, and build the index after loading representative data so it reflects real distribution. Keep provider keys in Edge Function secrets, never in client code. Watch memory: HNSW indexes are fast but memory-hungry, and that often sizes your plan more than raw storage does. The planner below estimates total vector storage and approximate index memory from your row count, embedding dimension, and index choice, so you can pick a Supabase tier before you hit a limit.