Supabase

Supabase is an open-source BaaS built on PostgreSQL; Firebase is Google's proprietary BaaS built on NoSQL (Firestore). Key differences: (1) Data model — Supabase uses relational PostgreSQL with full SQL; Firebase uses document-oriented NoSQL with a limited query API. (2) Vendor lock-in — Supabase is Apache 2.0 open source and self-hostable; Firebase is proprietary with no clean migration path. (3) Pricing — Supabase's compute-based monthly pricing is predictable; Firebase's per-operation model has produced unexpected bill spikes for many teams. (4) AI readiness — Supabase has pgvector first-class; Firebase has no native vector search. Both provide auth, real-time, storage, and functions — the fundamental choice is SQL + open source versus NoSQL + proprietary.

Yes. Supabase is used by Mozilla, GitHub, 1Password, Figma, Replit, Cursor, Zapier, and Vercel in production. A $2B valuation (April 2025) and $398M total funding reflect institutional confidence in its durability. Supabase offers SOC 2 Type II compliance, HIPAA-eligible configurations on Enterprise plans, 99.9% uptime SLA on Pro and higher, and dedicated support SLAs. The PostgreSQL foundation provides 35+ years of reliability. 3.5 million managed database environments and 8 million developers validate its production scale.

Supabase Auth is built on GoTrue (open-source) and supports: email + password (bcrypt), magic links, OAuth2/OIDC with any provider (Google, GitHub, Apple, Discord, LinkedIn, or any custom OIDC endpoint), phone OTP via SMS, SAML 2.0 for enterprise SSO, and anonymous users with optional conversion to permanent accounts. All tokens are JWTs signed with your project secret and decoded client-side without a network round-trip. PKCE is enabled by default for OAuth flows. JWTs carry user metadata and custom claims that RLS policies access via auth.uid() and auth.jwt() — no separate auth check in application code required.

RLS is a PostgreSQL feature Supabase exposes through its dashboard and CLI. You write SQL policies: CREATE POLICY 'Users see own data' ON profiles FOR SELECT USING (auth.uid() = user_id). PostgreSQL enforces this on every query — including direct database connections, the PostgREST API, and SQL run in the Supabase dashboard. The auth.uid() function returns the authenticated user's UUID from the JWT, making policies user-context-aware without application code changes. For multi-tenant applications, RLS is the most reliable isolation mechanism available — database-level policies cannot be bypassed by application bugs or misconfigured API routes.

pgvector adds vector data types and similarity operators to PostgreSQL. In Supabase: CREATE EXTENSION vector, add a vector(1536) column to your table, insert OpenAI or any model's embeddings, then query with SELECT content FROM documents ORDER BY embedding <=> query_embedding LIMIT 10. Create HNSW or IVFFlat indexes for millisecond similarity search at scale. The unique power of pgvector in Supabase: combine vector similarity with SQL WHERE clauses, JOINs, and full-text search in a single query — semantic search filtered by user permissions, date range, and document type, without a separate vector database.

Yes, and 125 production teams did it in tracked data through mid-2025. Supabase provides: (1) Firebase Auth migrator — imports users with bcrypt-hashed passwords; users log in normally with no password reset. (2) Firestore migration — documents migrate to PostgreSQL JSONB initially, then normalize to relational tables. (3) Firebase Storage — objects copy via gsutil + Supabase Storage import. (4) Cloud Functions → Edge Functions — TypeScript functions with full Supabase client access. Our migration playbook proceeds in phases with integrity validation at each step and zero-downtime cut-over. The 4.5:1 ratio of Firebase-to-Supabase versus the reverse reflects how well-established this migration path has become.

Edge Functions run TypeScript (Deno runtime) on globally distributed edge nodes with sub-100ms cold starts. Use them for: webhook handlers (Stripe, GitHub, Twilio) where you need server-side signature verification; AI inference calls to OpenAI or Anthropic before storing results; custom auth hooks running logic on sign-in or token refresh; CORS-sensitive server-side operations; and scheduled jobs triggered via pg_cron HTTP calls. Avoid Edge Functions for high-frequency user-facing hot paths (cold start matters there), CPU-intensive operations, or anything requiring persistent connections. Limits: 2MB bundle size, 10-second CPU time per invocation.

Supabase uses timestamped SQL migration files managed by the Supabase CLI. supabase migration new creates the file; you write DDL (CREATE TABLE, ALTER TABLE, CREATE POLICY, CREATE INDEX); supabase db push applies it to the target environment. Applied migrations are tracked in a schema_migrations table. Local development runs a complete Supabase stack via Docker (supabase start) — validate migrations locally before staging or production. The 2026 database branching feature creates isolated branches per feature branch, applying that branch's migrations independently for testing. We never modify existing migration files after deployment — all changes go in new migration files.

Supabase pricing: Free tier — 2 active projects, 500MB database, 1GB storage, 50MB Edge Function invocations, 2GB bandwidth. Pro — $25/month per project, 8GB database, 100GB storage, 250GB bandwidth, daily backups, 7-day log retention. Team — $599/month with SOC 2 compliance and HIPAA eligibility. Enterprise — custom pricing with dedicated support and SLA. Compute add-ons: $10–$450/month for upgraded instances. Storage add-on: $0.021/GB/month above included. Unlike Firebase's per-read/write billing that can spike on traffic bursts, Supabase's compute-based pricing scales linearly and is forecastable from a fixed monthly base.

Supabase provides Auth, real-time, storage, and auto-generated APIs out of the box — saving 4–8 weeks of backend infrastructure work on a new project. Choose Supabase when: you're building a new product where time-to-market matters, your requirements fit Supabase's managed constraints, and your team's strength is product rather than infrastructure. Choose a custom PostgreSQL backend when: you need PostgreSQL configurations or extensions Supabase doesn't support, you require components outside Supabase's scope, or your write throughput significantly exceeds managed tier capacity. For most products, Supabase's constraints are never reached — we evaluate this specifically for each project during scoping.