Supabase & PostgreSQL
We default to Supabase for new product builds and have migrated half a dozen clients off other databases to it. The reasons are operational: managed Postgres with the same SQL we'd use unmanaged, pgvector for embeddings without a separate vector DB to operate, Row Level Security for multi-tenant isolation enforced in the database (not the application), and the cost curve doesn't surprise us at scale the way enterprise database pricing tends to. The Horizon Labs platform itself runs on Supabase — 50+ tables, all multi-tenant by `site_id`, RLS policies across the board, pgvector for blog post similarity, edge functions for webhooks. We use what we recommend.
What you get
Real examples
Multi-tenant AI SaaS with strict data isolation
Illustrative scenario: a B2B AI product serving 50+ enterprise clients, each with their own document corpus. Supabase RLS policies enforce that no tenant can ever see another's documents, embedding queries, or chat history — at the database layer, even if the application layer has a bug. Compliance audit passes on the database design alone.
RAG over enterprise content using pgvector
Illustrative scenario: a media company replaces a separate Pinecone deployment with pgvector. Embeddings, source documents, and access controls all live in the same Postgres database — one backup, one set of credentials, one query layer. Performance is on-par for sub-10M document corpora; ops complexity drops significantly.
Real-time AI features via Supabase Realtime
Illustrative scenario: an operations dashboard streams AI-generated insights to multiple users simultaneously. Supabase Realtime broadcasts updates over WebSockets as the AI agent processes new data. No custom WebSocket server, no Redis pub/sub, no separate streaming infrastructure.
Common questions
Supabase vs Firebase or PlanetScale?
Different shapes. Firebase locks you into NoSQL document modelling — fine for some apps, painful for the relational reporting most B2B products eventually need. PlanetScale is excellent for MySQL at scale but doesn't have a native vector store or RLS equivalent. Supabase wins for AI-powered B2B because Postgres + pgvector + RLS in one platform removes 2-3 separate vendors from the architecture.
Is pgvector really good enough for production RAG?
Yes, up to ~10-20 million chunks per index. Above that, dedicated vector DBs (Pinecone, Weaviate, Qdrant) start to win on query latency and operations. For the projects we typically run, pgvector is the right call — fewer services to operate, embeddings and source data co-located, simpler backup story.
What happens if Supabase has an outage?
Supabase runs on AWS underneath, so cross-AZ HA is built in. We typically additionally configure read replicas and daily logical backups via wal-g to a separate region. For systems that genuinely cannot tolerate any downtime, we self-host Postgres on AWS RDS instead — same Postgres, different ops story.
Can you migrate us off Supabase if we outgrow it?
Yes. Because it's Postgres underneath, migration to AWS RDS, Aurora, or Google Cloud SQL is a `pg_dump` away. We've done this exit migration once for a client whose scale demanded enterprise-tier capacity at a lower ops budget. No data model rework needed — just a connection string change and a cutover.
How do you handle schema migrations?
Numbered SQL migration files (001_, 002_, ...) in version control, applied by a tiny custom runner during the build step. Every migration is forward-only and idempotent. We use this pattern on every Supabase project we run — including the Horizon Labs platform itself. 100+ migrations applied across two production sites with zero data loss.
Ready to get started?
Tell us about your project and we'll tell you honestly how we can help.
Get in Touch