Honest review of a backend platform that’s become the default choice for indie founders and AI startups. No vendor talking points — just what you’re actually getting.

TL;DR

What it is: Open-source (Apache-2.0) backend-as-a-service platform built on PostgreSQL — authentication, REST/GraphQL APIs, realtime subscriptions, storage, and edge functions, bundled into one dashboard [README].
Who it’s for: Developers and non-technical founders who want Firebase-level speed without a NoSQL database, vendor lock-in, or unpredictable per-operation billing [1][2].
Cost savings: Firebase charges per read/write/delete — costs spike fast at scale. Supabase Cloud’s free tier is generous, and self-hosted runs on any VPS. One developer described going from “how do I even start” to auth + database + realtime in 20 minutes [homepage].
Key strength: Real Postgres underneath — full SQL, joins, triggers, Row Level Security, extensions. Not a NoSQL database pretending to be relational [1][2].
Key weakness: Self-hosting the full stack is significantly more complex than the marketing suggests. You’re not self-hosting a single binary — you’re operating eight separate microservices. The gap between Supabase Cloud and Supabase OSS is wide [3][5].

What is Supabase

Supabase is a Postgres development platform. The README says it plainly: “We’re building the features of Firebase using enterprise-grade open source tools.” That’s a more honest pitch than the homepage’s “Build in a weekend, Scale to millions” headline, but both capture something real [README].

What Supabase actually ships is a stack of open-source components assembled behind a single dashboard. The database is standard PostgreSQL. REST API access comes from PostgREST, which reads your schema and auto-generates endpoints. GraphQL comes from pg_graphql, a PostgreSQL extension. Authentication is GoTrue, a JWT-based auth server. Real-time database change broadcasting is a separate Elixir service that listens to Postgres replication slots and fans out over WebSockets. File storage is its own RESTful API backed by S3-compatible storage with Postgres handling permissions. Edge Functions run on Deno. Kong sits in front as the API gateway [README].

Each of these components is individually open-source. Supabase’s contribution is making them work together behind a coherent interface, and that’s worth something — particularly the dashboard, which handles SQL editing, table management, RLS policy writing, and storage management without requiring you to know every service’s native interface.

The project has 99,159 GitHub stars, which puts it in a small category of infrastructure tools that developers genuinely recommend to each other [merged profile]. That kind of adoption doesn’t happen from marketing.

Why people choose it over Firebase

The comparison Supabase picks for itself is Firebase, and it’s the right one to examine carefully.

The database structure mismatch with Firebase. Jake Prins, a developer with over a decade of experience, wrote a detailed comparison after using both professionally [1]. His core complaint about Firebase: Firestore’s NoSQL model fought his mental model of relational data. He’d spent years working with PostgreSQL and kept wanting to write joins that Firestore can’t express. Supabase gave him SQL back. That’s the recurring theme in developer testimonials — not that Firebase is bad, but that Firebase punishes you for thinking in tables and relationships [1][2].

The pricing structure anxiety. Firebase charges per read, write, and delete operation. At low volume this is negligible. At scale, it becomes genuinely unpredictable — you can’t easily calculate next month’s bill from first principles. A cache miss, a missing index, or a mobile app update that queries more aggressively can cause a billing spike that arrives weeks later. Supabase’s pricing model is compute-based: you pay for the database instance, not for individual operations [1][2]. That predictability matters more than the absolute price for many teams.

The open-source licensing and self-hosting option. Firebase is entirely proprietary. If Google discontinues a service, changes pricing, or the product direction diverges from your needs, your data is in their schema and your authentication users are in their system. Supabase is Apache-2.0 licensed and provides a docker-compose for local development. The theoretical escape hatch exists [3].

The developer experience. Community testimonials on the homepage and in reviews consistently mention fast time-to-something-working. The MCP integration has become a specific draw — developers describe using Claude Code with the Supabase MCP to create migrations, write RLS policies, and check schema state without leaving the AI assistant [homepage]. One tweet quoted on the homepage: “Loving #Supabase MCP. Claude Code would not only plan what data we should save but also figure out a migration script by checking what the schema looks like on Supabase via MCP.”

The honest counterpoint: the developer experience is primarily the Cloud product. The OSS self-hosted version offers no such guarantee [3][5].

Features

Core database:

Full PostgreSQL — every extension, every SQL feature, every migration tool in the ecosystem works [README]
Dashboard with table editor, SQL editor, and schema visualizer [README][homepage]
Row Level Security policies managed through the dashboard or SQL [README][2]
Database functions (PL/pgSQL and other procedural languages) [README]
Scheduled jobs via pg_cron extension [README]

Auto-generated APIs:

REST via PostgREST — your schema becomes endpoints automatically, no code to write [README][2]
GraphQL via pg_graphql — same schema, different query style [README]
Realtime subscriptions — listen to INSERT/UPDATE/DELETE events over WebSockets [README][2]

Authentication:

Email/password, magic links, social providers (Google, GitHub, Apple, etc.) [README][2]
Multi-factor authentication [2]
JWT-based sessions integrated directly with PostgreSQL Row Level Security [2]
Programmatic access control at the row level based on the authenticated user’s JWT claims [2]

Storage:

File upload API with S3 backing [README]
Access control enforced through Postgres permissions [README]
Image transformations via imgproxy (bundled in self-hosted) [4]

Edge Functions:

Deno-based serverless functions deployable from the CLI [README]
Can access the database directly [README]

Vector / AI:

pgvector integration for storing and querying embeddings [README][homepage]
Native support for OpenAI and Hugging Face embeddings workflows [homepage]

Developer tooling:

Supabase CLI for local development with migrations [README]
MCP server for AI assistant integration [homepage]
Client libraries for JavaScript/TypeScript, Python, Dart, Swift, Kotlin, C#, and community-maintained others [README]

Pricing: SaaS vs self-hosted math

Supabase Cloud:

Free: 500MB database, 1GB storage, 50,000 monthly active users, 500,000 edge function invocations, 2GB realtime messages. Pauses after 1 week of inactivity [pricing page].
Pro ($25/mo): 8GB database, 100GB storage, 100,000 MAUs, no project pausing, daily backups, 7-day point-in-time recovery [pricing page].
Team ($599/mo): SOC 2 compliance, HIPAA add-on available, 28-day PITR, priority support [pricing page].
Enterprise: Custom pricing, contact sales [pricing page].

Self-hosted:

License: $0 (Apache-2.0) [README]
Server requirements: minimum 4GB RAM, 2 CPU cores, 50GB SSD — recommend 8GB RAM, 4 cores for production [4]
VPS cost: $15–40/mo on Hetzner, Contabo, or DigitalOcean for the recommended spec

Firebase for comparison (Spark → Blaze):

Spark plan is free with hard limits
Blaze (pay-as-you-go): Firestore charges $0.06 per 100,000 reads, $0.18 per 100,000 writes, $0.02 per 100,000 deletes
A moderately active app with 1M reads and 200K writes per day hits roughly $18–25/day — $540–$750/month before storage and bandwidth [1]

Concrete math for a founder running an app with 50K monthly active users and modest read/write volume:

Firebase Blaze: data not available to calculate precisely without specific read/write counts — but the per-operation model means any traffic spike hits your bill
Supabase Cloud Pro: $25/month flat for 100K MAUs — the instance cost is fixed regardless of query count
Supabase self-hosted: $15–25/month VPS + your time

The self-hosted option looks attractive on paper. The catch is the operational burden, which the next section addresses directly.

Deployment reality check

The official Docker documentation [4] is honest about prerequisites in a way that the marketing is not: “This guide assumes you’re comfortable with Linux server administration basics, Docker and Docker Compose, and networking fundamentals.” It then recommends 4GB RAM minimum, 8GB for production, 2 CPU cores minimum, 4 recommended. That’s a $20–30/month VPS, not a $5 instance.

The installation process itself — cloning the repo, copying the compose files, generating secrets — takes 30 minutes if you know what you’re doing [4]. The configuration step is where things get complicated. You need to generate a JWT secret, derive ANON_KEY and SERVICE_ROLE_KEY from it, configure a database password, set SMTP for email auth, configure a domain and reverse proxy for HTTPS, and decide which services you actually need (Logflare/analytics alone is a significant resource consumer that most small deployments disable) [4].

What you’re actually running in production is: PostgreSQL, PostgREST, GoTrue (auth), Supabase Realtime (Elixir), Storage API, pg_graphql (extension), postgres-meta, Kong (API gateway), and optionally analytics, imgproxy, and Edge Functions runtime [README][4]. Each service has its own update cadence, configuration, and failure modes.

Sachin Agarwal’s Medium piece [3] from 2023 identifies the structural gap clearly: the community Helm charts are “starting points rather than production-ready manifests.” The company’s focus is the SaaS product. Self-hosting is supported but not a first-class product. The practical implication: when you hit an edge case in the self-hosted stack, you’re largely on your own with GitHub Issues and the Discord community.

Simplyblock’s analysis [5] makes the cost argument bluntly: “A single full-time platform engineer can cost more than a managed database subscription.” Self-hosting Supabase at a real production scale means someone on your team owns database patching, realtime service upgrades, storage API updates, and incident response. For a bootstrapped founder, that someone is you.

The honest summary: self-hosting Supabase for development and staging is practical. Self-hosting it for production at scale, without a platform engineer, is a bet that your operational time is cheaper than $25–$599/month.

Pros and cons

Pros

Real Postgres. Every extension, every tool, every query pattern that works in PostgreSQL works here. No relearning a proprietary query language [1][2].
Row Level Security is excellent. Writing security policies in SQL at the database level, rather than in application middleware, means security rules can’t be accidentally bypassed by a new API route [2][homepage].
Auto-generated REST and GraphQL APIs. PostgREST turns your schema into usable endpoints without any code. For CRUD-heavy applications, this eliminates entire layers of boilerplate [2][README].
Apache-2.0 license. More permissive than many “open-core” competitors. No commercial redistribution restrictions, no “Fair-code” clauses [README].
MCP integration. The Supabase MCP server is one of the better AI assistant integrations available — developers describe it as genuinely useful for migrations and schema exploration [homepage].
99K+ GitHub stars. That’s not a vanity metric at this scale — it reflects a large community, broad third-party library support, and a lot of public knowledge about debugging common problems [merged profile].
Dashboard quality. The SQL editor, table editor, and RLS policy UI are genuinely well-designed. Non-technical founders can do a lot without writing SQL [homepage][1].

Cons

Self-hosting complexity is significantly undermarketed. You’re not deploying one service — you’re deploying eight coordinated microservices. The documentation is honest about it, the homepage is not [4][5].
Self-hosted OSS ≠ Supabase Cloud. Features and update frequency differ. The cloud product gets improvements the OSS version receives later, sometimes much later [3][5].
Realtime at scale is operational noise. Maintaining Postgres replication slots, managing WebSocket fan-out, and handling message ordering under load requires real infrastructure knowledge [5].
No official on-premises product. Supabase the company’s focus is the SaaS. Self-hosting is community-supported with company-provided starting points. Enterprise self-hosting support appears to be in progress but isn’t the primary offering [3].
AWS region lock for Supabase Cloud. Your database lives in one of Supabase’s AWS regions. If your users or application servers are elsewhere, latency is on you [3].
Limited analytics connectivity. Syncing large Supabase Postgres databases to data warehouses (BigQuery, Redshift) is not well-supported in the managed product. Self-hosted gives you more options but more work [3].
Edge Functions runtime (Deno) is an ecosystem minority. Most Node.js libraries work, but not all, and Deno-first development has a smaller community and fewer examples than Node [README].
The free tier pauses after inactivity. For prototype demos and side projects, a week of no traffic can mean a cold-start experience for the next visitor [pricing page].

Who should use this / who shouldn’t

Use Supabase (Cloud) if:

You’re building a web or mobile app and want auth, database, storage, and APIs without building and maintaining each separately.
You think in SQL and relational data, and Firebase’s NoSQL model has frustrated you before.
You’re a solo founder or small team and the $25/mo Pro plan is a reasonable trade for not managing database infrastructure.
You’re building AI features and want a managed pgvector deployment without a separate vector database subscription.
You want to use the Supabase MCP with Claude, Cursor, or similar AI coding tools.

Use Supabase (self-hosted) if:

You’re in a regulated industry that requires data to stay in a specific VPC or geography that Supabase Cloud doesn’t serve [3].
You have a platform engineering team that owns database infrastructure and you need maximum customization over Postgres configuration [3][5].
You want to embed Supabase’s stack into your own product under the Apache-2.0 license.

Skip it (stay on Firebase) if:

Your data is inherently unstructured or document-based and you don’t need relational queries.
Your team has deep Firebase expertise and the per-operation pricing is manageable at your volume.
You need Google Cloud integrations (Vertex AI, BigQuery, Cloud Run) and want tight native connectivity.

Skip it (use plain managed Postgres) if:

You only need a database — not auth, storage, realtime, or edge functions — and you’re comfortable writing your own API layer.
The realtime and auth services add complexity you won’t use.

Skip it (self-hosted) if:

You’re a solo non-technical founder without a developer on the team. The setup and ongoing maintenance is a real cost.
You want to self-host to save money and you’re calculating only the VPS cost, not your time [5].

Alternatives worth considering

Firebase — the incumbent Supabase competes against directly. Faster initial setup for document-oriented data, proprietary, per-operation pricing, no self-hosting [1].
PocketBase — a single-binary alternative for smaller applications. Dramatically simpler to self-host. Not Postgres, and won’t scale to millions of users, but for projects that don’t need that, it’s significantly less operational burden.
Neon — serverless Postgres with branching and a generous free tier. Just the database — no auth, no storage, no realtime. Good if you want Postgres without the full Supabase stack.
Appwrite — similar positioning to Supabase (Firebase alternative, self-hostable, open-source). Uses MariaDB under the hood instead of Postgres. Smaller community.
Convex — TypeScript-native backend with reactive queries. Opinionated about how you structure code. Not open-source but a different take on the same problem space.
Plain Postgres on Railway or Render — if you only need a database and you’re comfortable writing your own auth and API layer, a managed Postgres instance on Railway starts at $5/month with no added complexity.

Bottom line

Supabase has earned its position as the default backend-as-a-service recommendation for developers who want Firebase speed with relational data. The product is genuinely good: Postgres stays Postgres, the dashboard is well-designed, and the combination of auth + REST API + realtime + storage removes real work for small teams. The 99K+ star count reflects actual developer satisfaction, not marketing spend.

The honest qualification is that “self-hosted Supabase” and “Supabase Cloud” are meaningfully different products, and the gap matters when you’re making an infrastructure decision. If you’re a non-technical founder or a small team, the Cloud product at $25/month is the right call — the operational cost of self-hosting the full eight-service stack almost certainly exceeds the subscription cost unless you have dedicated platform engineering capacity. If you want the escape hatch of open-source without the operational burden of self-hosting it yourself, that’s a reasonable trade to make. The Apache-2.0 license means the data and schema are portable — you can always move later.

For non-technical founders specifically: start on Supabase Cloud, not self-hosted. The $25/month Pro plan buys you a real production database with daily backups, managed auth, and an environment that won’t require debugging Docker networking at 2am. If you hit the point where $599/month for the Team plan is meaningful money, you’ll have the revenue and team to make a more informed self-hosting decision.

Sources

Jake Prins — “Supabase vs Firebase: Choosing the Right Backend for Your Next Project” (jakeprins.com). https://www.jakeprins.com/blog/supabase-vs-firebase-2024
QualityPoint Tech Blog — “Supabase: The Open-Source Firebase Alternative You Need to Know” (blog.qualitypointtech.com). https://www.blog.qualitypointtech.com/2025/09/supabase-open-source-firebase.html
Sachin Agarwal, Medium — “The Case For Better Self-hosting Supabase Support” (medium.com). https://medium.com/@sachin_49501/the-case-for-better-self-hosting-supabase-support-dbdab63df3fa
Supabase Official Docs — “Self-Hosting with Docker” (supabase.com). https://supabase.com/docs/guides/self-hosting/docker
Simplyblock / Vela — “Self-Hosting Supabase vs Managed Postgres: Control, Cost, and Complexity” (vela.simplyblock.io). https://vela.simplyblock.io/articles/self-hosting-supabase/