Do we need a separate vector database?

Usually not. pgvector comfortably handles the corpus sizes most business RAG systems have, and keeping vectors beside your relational data makes permission-aware retrieval straightforward. Dedicated vector stores earn their place at much larger scale or with specialised requirements.

Yes — Supabase is open source and runs on your own infrastructure. Most teams start on the hosted platform and only move if compliance requires it, since self-hosting shifts real operational burden onto you.

Database + auth · Integration

Alian AI for Supabase

Postgres-native RAG, pgvector retrieval, and auth — without leaving Supabase.

Supabase development is our default for new projects without an existing data layer. Postgres with pgvector covers most RAG needs out of the box, Supabase Auth handles auth, and Edge Functions run light orchestration.

Scope an integration →Try our AI on your problem ↑

Things we've built on Supabase

RAG-native chatbots with pgvector
Multi-tenant auth with row-level security
Edge Functions for streaming AI responses

How the integration actually works

Postgres with pgvector covers retrieval, Supabase Auth covers identity, and Edge Functions handle light orchestration and response streaming. For a RAG build this means embeddings, application data, and permissions all live in one database — so retrieval can be filtered by the same row-level security rules that govern the rest of the app. That is considerably harder when vectors sit in a separate store with its own access model.

What to watch for on Supabase

The constraints that decide whether this ships in weeks or drags — worth knowing before you scope, whoever builds it.

Row-level security is off until you turn it on: RLS is the security boundary in Supabase and it is not enabled by default on new tables. A multi-tenant RAG system without it will happily retrieve another tenant's documents. Enable it per table and test with real tenant tokens, not service keys.
Index choice is a real tradeoff: pgvector offers HNSW and IVFFlat. HNSW gives better recall and query latency at the cost of build time and memory; IVFFlat is cheaper to build but needs its list count tuned. Choose deliberately against your corpus size and revisit it once the corpus grows.
Pool your connections: Serverless functions open connections aggressively and Postgres has a hard ceiling. Route through the connection pooler rather than connecting directly, or you will hit exhaustion under precisely the load you built the system to handle.

Questions we get about Supabase

Do we need a separate vector database?: Usually not. pgvector comfortably handles the corpus sizes most business RAG systems have, and keeping vectors beside your relational data makes permission-aware retrieval straightforward. Dedicated vector stores earn their place at much larger scale or with specialised requirements.
Can we self-host it?: Yes — Supabase is open source and runs on your own infrastructure. Most teams start on the hosted platform and only move if compliance requires it, since self-hosting shifts real operational burden onto you.