Supabase: The Open Source Firebase Alternative Built on PostgreSQL

Firebase solved a real problem: give developers a complete backend without requiring backend expertise. Authentication, a database, file storage, and real-time updates — all accessible through a clean SDK, deployed in minutes. Millions of apps run on it. The problem is what you trade for that convenience: your data lives in Google's proprietary Firestore format, your queries are constrained by a NoSQL model, and migrating away means rewriting your data layer from scratch.

Supabase offers the same developer experience with a fundamentally different foundation. Instead of a proprietary NoSQL engine, it's PostgreSQL — the world's most trusted relational database. Instead of vendor lock-in, it's Apache 2.0-licensed and fully self-hostable. The pitch is Firebase's developer experience with SQL and data portability.

In 2026 Supabase has 103,000+ GitHub stars, a $5 billion valuation, 1,893 contributors, and powers everything from solo projects to production apps at publicly traded companies. It's not a Firebase clone — it's a genuinely mature platform that happens to feel familiar.

What Supabase is

Supabase is an open-source Backend-as-a-Service platform built on PostgreSQL. It wraps a set of open source tools — each independently useful — into a unified platform with a single dashboard and a consistent client SDK:

• PostgreSQL — a real, full-featured Postgres database. Not a simplified subset, not a proprietary engine with SQL syntax bolted on. Real Postgres, with all extensions, full SQL, RLS, triggers, and functions.
• Auth — user authentication with email/password, magic links, OAuth (Google, GitHub, Apple, and 20+ more providers), phone OTP, and SAML for enterprise SSO. Built on GoTrue, Apache 2.0 licensed.
• Realtime — listen to database changes, broadcast messages, and track presence via WebSockets. Built with Elixir/Phoenix, capable of millions of concurrent connections.
• Storage — S3-compatible file storage with CDN, image transformations, and fine-grained access control through RLS policies. Apache 2.0 licensed.
• Edge Functions — globally distributed TypeScript/JavaScript functions running on Deno. Deploy serverless logic close to your users.
• Auto-generated APIs — every table automatically gets a REST API (via PostgREST) and a GraphQL API. Zero configuration, secured by RLS.
• pgvector — the PostgreSQL extension for vector embeddings ships as a default. Supabase became the fastest path to a RAG backend in 2023–2024 for exactly this reason.

The license — genuinely Apache 2.0

After a string of posts on this blog covering source-available tools (Outline's BSL, Invoice Ninja's ELv2, Dify's modified Apache 2.0, Nomad's BUSL), Supabase is worth calling out explicitly: it's Apache 2.0, genuinely OSI-approved open source, with no commercial-use clauses, no multi-tenant restrictions, no logo requirements. Use it however you want. Self-host it, fork it, build a competing hosted service — Apache 2.0 permits all of it.

The company's philosophy from the GitHub README: "If the tools and communities exist with an MIT, Apache 2, or equivalent open license, we will use and support that tool. If the tool doesn't exist, we build and open source it ourselves." They've followed through — every component in the stack is independently open source.

Row Level Security — the key concept

The feature that makes Supabase's approach coherent is Row Level Security (RLS). In a traditional BaaS, access control is managed in the API layer — your serverless functions check whether a user is allowed to see a row before returning it. In Supabase, access control lives in the database itself as PostgreSQL policies.

A policy might look like this:

-- Users can only see their own data
create policy "Users can view own profile"
  on profiles for select
  using ( auth.uid() = user_id );

-- Only owners can update their records
create policy "Users can update own profile"
  on profiles for update
  using ( auth.uid() = user_id );

These policies enforce at the database layer — even if someone bypasses your API and queries the database directly, they still can't see data they're not authorized to see. The auto-generated REST and GraphQL APIs respect these policies automatically. You write the policy once and every access path is covered.

This is a genuinely different security model than most BaaS platforms, and it's one of Supabase's strongest architectural arguments.

Auto-generated TypeScript types

One quality-of-life feature worth highlighting: Supabase generates fully typed TypeScript types from your database schema. Every table, every column, every foreign key relationship — typed automatically.

supabase gen types typescript --project-id your-project-id > database.types.ts

The result is end-to-end type safety from your database through to your frontend. Change a column type in the database, regenerate types, and TypeScript will catch every affected query and component. For teams building TypeScript applications, this removes an entire category of runtime errors.

pgvector and AI applications

Supabase ships the pgvector extension by default, which makes it a natural backend for AI applications that need vector search. Store embeddings alongside your regular data in the same database, query with standard SQL, and combine semantic similarity search with structured filters in a single query:

-- Find similar documents, only from public posts
select id, title, content
from documents
where status = 'published'
order by embedding <-> query_embedding
limit 10;

This "one database for everything" approach — relational data, vector embeddings, and full-text search all in PostgreSQL — is what made Supabase the default choice for RAG-backed applications. You get pg_trgm for fuzzy search, pgvector for semantic search, and standard SQL for structured filters, all in one query, without a separate vector database to manage.

Self-hosting Supabase

Supabase is self-hostable via Docker Compose. The stack is more complex than most tools on this blog — it runs around a dozen services — but the official Docker Compose configuration handles the wiring:

# Clone the repo
git clone --depth 1 https://github.com/supabase/supabase

cd supabase/docker

# Copy the example env and configure
cp .env.example .env
# Edit .env: set POSTGRES_PASSWORD, JWT_SECRET, ANON_KEY, SERVICE_ROLE_KEY

# Pull and start
docker compose pull
docker compose up -d

The full stack includes: PostgreSQL, PostgREST (auto REST API), GoTrue (auth), Realtime (websockets), Storage API, Kong (API gateway), Postgres Meta (database management), Supavisor (connection pooler), and the Studio dashboard. It's a lot of services, but each is independently useful and the Docker Compose configuration is well-maintained.

Minimum viable server: 4GB RAM, 2 CPU cores. For production, 8GB+ and separate database storage is recommended. The official Supabase self-hosting docs are comprehensive and actively maintained — this is not an afterthought.

Supabase vs Firebase

This is the comparison that matters for most teams evaluating Supabase.

Data model — Supabase is PostgreSQL: relational, SQL, JOINs, transactions, foreign keys, complex queries. Firebase Firestore is NoSQL: documents, collections, no JOINs, no multi-document transactions (except in limited form). For any data with relationships — users, posts, comments, orders, products — PostgreSQL's model is significantly more expressive.

Data portability — Supabase's data is in standard PostgreSQL. Export with pg_dump, connect any SQL tool, migrate to RDS, Google Cloud SQL, or a self-hosted Postgres. Firebase data is in Firestore's proprietary format — exporting and migrating requires custom scripts and model transformation. Every year you use Firebase, migration gets harder.

Lock-in — Firebase Auth tokens are Firebase-specific. Cloud Functions run on Google Cloud only. Firestore's query language is proprietary. Every convenience ties you deeper into Google's ecosystem. Supabase's components are independently open source — GoTrue for auth, PostgREST for APIs, PostgreSQL for data. You could replace any component independently.

Real-time — Firebase's real-time was the original killer feature. Supabase Realtime is competitive and uses standard PostgreSQL CDC (change data capture), meaning it reflects actual database state rather than a separate real-time layer.

Ecosystem — Firebase has a decade head start and deeper mobile SDK integrations (especially for iOS/Android), push notifications, Firebase Analytics, and Crashlytics. For mobile-first apps, Firebase's broader service set is still relevant. For web and API-first apps, Supabase covers the core backend needs well.

Supabase vs Appwrite

Appwrite is the other major open source BaaS alternative, and it's worth a direct comparison since both target the same audience.

Supabase is PostgreSQL-first — the database is the product, and everything else wraps around it. If you want the power of a real relational database with auto-generated APIs and auth on top, Supabase is the better choice. Appwrite uses its own database abstraction layer over multiple backends, which is more flexible but gives up some of PostgreSQL's depth.

Appwrite has a stronger multi-platform story (native SDKs for more platforms), a built-in messaging system, and arguably simpler self-hosting. For mobile-first applications or teams that prefer a more abstracted data model, Appwrite is worth evaluating. For web applications and teams who want real SQL, Supabase wins.

Pricing

Supabase Cloud's free tier is generous: 500MB database, 1GB storage, 50K monthly active users, unlimited API requests. The Pro plan is $25/month for 8GB storage and 250GB bandwidth.

Self-hosted is free beyond infrastructure costs — no license fees, no feature gates, no user limits. All features including the Studio dashboard, Edge Functions, and Realtime are available in the self-hosted version.

Who it's for

Good fit:

• Teams building web apps or SaaS products that want a complete backend without writing backend code
• Projects coming from Firebase that want data portability and SQL
• AI application developers who need vector search alongside relational data (pgvector)
• TypeScript-first teams who want database-to-frontend type safety
• Teams with compliance or data residency requirements — self-host and own everything
• Developers who know SQL and want to use it, not work around a NoSQL limitation

Not the right fit:

• Mobile-first apps needing Firebase's push notifications, Analytics, and Crashlytics — Firebase's mobile ecosystem is deeper
• Teams needing a simple, lightweight single-binary backend — PocketBase is far simpler to self-host
• Applications with pure document-based data models and no relational needs — Firebase/Firestore works better for those
• Teams without capacity to operate a 10+ service Docker stack in self-hosted mode

My take

Supabase is one of the cleanest examples of what open source done right looks like. The license is genuinely Apache 2.0 — not "Apache 2.0 but not really." Every component in the stack is independently open source. The data sits in standard PostgreSQL. And the developer experience is genuinely good: the dashboard is polished, the SDKs are well-typed, and the auto-generated APIs with RLS policies eliminate a class of backend code you'd otherwise have to write.

The self-hosting story is also mature in a way that most BaaS platforms aren't — this isn't an afterthought for compliance cases, it's a first-class deployment path that the team actively maintains. For teams with data sovereignty requirements, or simply teams that want to not pay per-MAU fees as they scale, self-hosted Supabase is a real option.

The complexity trade-off is real: the self-hosted stack is a dozen services, and operating it correctly requires more DevOps discipline than most simpler tools. But if you're already running a self-hosted infrastructure stack — and if you're reading this blog you probably are — Supabase fits naturally into that picture. It's one more Docker Compose deployment, and what you get in return is a complete, standards-based backend for every application you want to build.