Supabase vs Firebase

Most "Supabase vs Firebase" articles compare two hosted services. This one asks a different question: what happens if you run Supabase on your own server instead of building on Google's Firebase? Supabase publishes an official Docker Compose stack for exactly that. Firebase has no self-hosted edition at all. Google's own docs say its local emulators are not one, and warn against using them in production. So the real choice is between a managed Google platform and a Postgres backend you operate.

What each one actually is

Firebase is Google's app platform, and it is hosted only. Its build products include Authentication, Cloud Storage, Cloud Functions, Hosting, and two NoSQL databases: Firestore and the older Realtime Database. Around those sit the "run" products that mobile teams rely on: Crashlytics, Cloud Messaging, Remote Config, A/B Testing, Google Analytics, Test Lab and App Distribution. There is a no-cost Spark plan that needs no payment method. The pay-as-you-go Blaze plan includes the Spark allowances and bills for usage beyond them. Some products need Blaze. Cloud Functions is one: its docs tell you to upgrade to Blaze before you deploy.

Self-hosted Supabase is the open-source Supabase stack (Apache-2.0), run from the docker directory of the Supabase repository. The Compose file starts Postgres and the services built around it:

• Auth for sign-ups, logins and sessions
• PostgREST, which turns your schema into a REST API
• Realtime, which broadcasts database changes
• Storage for files, with Postgres handling permissions
• Edge Runtime, a Deno server for functions
• Supavisor for connection pooling
• Studio as the dashboard
• An API gateway in front of it all

Supabase's docs list 4 GB of RAM, 2 CPU cores and a 40 GB SSD as the minimum, and recommend 8 GB, 4 cores and 80 GB.

Hosted Supabase is not what you get on your VPS

Supabase's docs list what the hosted platform has and self-hosting does not: "Branching, advanced metrics beyond logs, managed backups and PITR, analytics and vector buckets, ETL, and the platform management API are unavailable." Logs & Analytics is also off by default, and turning it on adds more services and more RAM. Self-hosted Supabase is community-supported. Backups, disaster recovery, security hardening, high availability and Postgres maintenance are all your job. On the plus side, the self-hosted stack "does not phone home or collect any telemetry."

The real difference: the data model

Firestore is, in Google's words, "a NoSQL, document-oriented database." It is schemaless. Documents live in collections, and you model relationships with nested objects and subcollections, not joins. Its SDKs cache the data your app is using, so the app can keep reading, writing and querying while the device is offline. If your app depends on that, check how you would replace it before you migrate.

Supabase is Postgres. Its docs put it plainly: "Every Supabase project gets a full Postgres database, not a Postgres abstraction." You get SQL, foreign keys and joins. You can add extensions such as pgvector, PostGIS and pg_cron. Authorization is written as Row Level Security policies inside the database. Realtime offers Broadcast, Presence and Postgres Changes, which is a listener on table changes, not a document sync engine.

Firebase is no longer NoSQL-only, though. It now offers SQL Connect (formerly Data Connect), which is backed by Cloud SQL for PostgreSQL and queried through GraphQL. Beyond a three-month no-cost trial it needs the Blaze plan, and it is still Postgres on Google Cloud, not on your server.

Lock-in and leaving

A self-hosted Supabase database is ordinary Postgres. pg_dump works on it, standard connection strings work, and any Postgres host can restore it. Firestore data has no self-hosted home. Moving off means converting documents into tables.

Supabase documents that path with community tools. Each Firestore collection becomes one Postgres table with text, numeric, boolean or jsonb columns. Anything more deeply nested has to be split into related tables by your own script. Firebase Auth users can be exported and loaded into Supabase's auth.users table. You need Firebase's password-hash parameters for this. The guide points to a middleware approach, which checks each user's old password the first time they log in, for more advanced migrations. Plan it as a data migration project: you are redesigning the schema, not flipping a switch.

What has no self-hosted equivalent

None of Firebase's run products appears among the services self-hosted Supabase starts: Crashlytics, Cloud Messaging push, Remote Config, A/B Testing, Analytics, Test Lab, App Distribution. The same goes for App Check, Hosting and the Gemini-based AI Logic SDKs. For a mobile team, that list can matter more than the database. Supabase replaces Firebase's backend: data, auth, storage, functions and realtime. For the rest you keep Google's services or pick separate tools.

Which to choose

Choose Firebase if you want zero operations. It also wins if your app leans on offline-first document sync, or on push, crash reporting and remote config from one console, and you are comfortable with a usage-based bill and data that lives in Google's cloud.

Choose self-hosted Supabase if you want a relational database you own and a flat server bill. It fits when data residency or portability matters, or when you already think in SQL. Budget a real box of at least 4 GB, and be ready to handle backups, upgrades and security for a multi-container stack that comes with community support only.

If you like Supabase's model but don't want to operate it, hosted Supabase is the middle ground. It adds managed backups and PITR, which the self-hosted stack lacks.

Running Supabase on a VPS

The Supabase page has the official Compose install, and the Supabase deployment guide walks through secrets, TLS and first boot. If a dozen-plus containers sounds like too much, PocketBase vs Supabase compares it with a single-binary backend, and Supabase vs Appwrite with a document-style one. For every self-hosted option we list against Firebase, see Firebase alternatives.