# Supabase alternatives: an honest comparison

> The right Supabase alternative depends on what you want to change: the whole backend (Firebase, Appwrite), just the database (Neon), or only the host.

Source: https://supahost.app/guides/supabase-alternatives · Updated 2026-11-11

There is no single best Supabase alternative, because people leave Supabase for different reasons. If you want a different kind of backend, look at Firebase, Appwrite, Nhost, PocketBase or Convex. If you only want Postgres, a serverless host like Neon plus your own auth works well, and if you like Supabase but not its pricing or hosting model, you can keep Supabase and run it somewhere else.

Facts about each product below come from its official site or repository, checked in November 2026.

## Start with what you actually want to change

- **"I don't like the developer model."** You want a different backend-as-a-service (BaaS) with its own API and data model.
- **"I only need a database."** You use Supabase mainly as hosted Postgres and could handle auth, files and APIs yourself.
- **"I like Supabase, but not the bill or the hosting."** Your code and RLS policies are fine; you want to change where it runs or how it's priced.

The difference in effort is large. Moving to a different backend means rewriting data access, auth and often your schema. Changing hosts usually means changing a URL and two keys.

## Option A: a different backend-as-a-service

### Firebase

**What it is.** Google's app platform: Firestore (a NoSQL document database), Authentication, Cloud Storage, Cloud Functions, Hosting and a long list of mobile tools. Firebase also now offers SQL Connect (renamed from Data Connect in 2026), which puts a GraphQL layer over [PostgreSQL on Cloud SQL](https://firebase.google.com/docs/data-connect).

**Best for.** Mobile-first apps, teams already on Google Cloud, and products that use Firebase's wider toolkit such as push notifications, analytics and crash reporting.

**Trade-offs.** Firestore is a document store, so relational data and ad-hoc queries take more planning than in SQL. You are tied to Google's platform and its usage-based pricing.

**Licence and hosting.** Proprietary and cloud-only. The Local Emulator Suite is for development, not production.

### Appwrite

**What it is.** An open-source BaaS with Auth, Databases, Storage, Functions, Realtime, Messaging and Sites (frontend hosting), according to its [GitHub repository](https://github.com/appwrite/appwrite). Its built-in databases are reached through Appwrite's API, with relational tables, schemaless documents and vectors as options; it also offers managed PostgreSQL and MySQL on [dedicated infrastructure](https://appwrite.io/docs/products/databases).

**Best for.** Teams that want a broad, Firebase-style feature set they can self-host.

**Trade-offs.** By default you work through Appwrite's API and permission model rather than writing SQL and RLS policies against Postgres. Moving to or from Appwrite is a real rewrite.

**Licence and hosting.** BSD 3-Clause. Self-host with a Docker-based installer, or use Appwrite Cloud, which has a free plan.

### Nhost

**What it is.** An open-source backend built on PostgreSQL with an instant GraphQL API from Hasura, plus Nhost's own auth and storage services and Node.js functions ([GitHub](https://github.com/nhost/nhost)).

**Best for.** Teams who want Postgres underneath but prefer GraphQL to REST, and who are comfortable with Hasura's permission system.

**Trade-offs.** GraphQL-first, so REST-style supabase-js code does not carry over. Permissions live in Hasura rather than mainly in RLS. The community is smaller than Supabase's or Firebase's.

**Licence and hosting.** MIT. Self-host with the example Docker Compose setup, or use the Nhost hosted platform.

### PocketBase

**What it is.** A backend in a single Go executable: an embedded SQLite database, users and auth, file storage, realtime subscriptions and an admin UI ([GitHub](https://github.com/pocketbase/pocketbase)). You can also use it as a Go library and extend it.

**Best for.** Prototypes, internal tools, side projects and small apps where one cheap server is plenty and simplicity matters most.

**Trade-offs.** It runs on one server with SQLite, so it scales up, not out. It is still pre-1.0, and the project says backward compatibility isn't guaranteed until v1.0.0. There is no official hosted service; you run it yourself.

**Licence and hosting.** MIT. Self-hosted only.

### Convex

**What it is.** A reactive backend where you write queries and mutations as TypeScript functions, and clients update automatically when data changes. It has its own database and data model rather than SQL ([GitHub](https://github.com/get-convex/convex-backend)).

**Best for.** TypeScript teams building highly interactive apps (collaboration, live dashboards) who want end-to-end type safety and don't need SQL.

**Trade-offs.** No SQL and no Postgres-level access for your app, and the programming model is specific to Convex. Self-hosting is supported, but the hosted cloud is the main, best-tested path.

**Licence and hosting.** Source-available under [FSL-1.1-Apache-2.0](https://github.com/get-convex/convex-backend/blob/main/LICENSE.md): each version becomes Apache 2.0 two years after release, and until then you can't use it to offer a competing service. Self-host with Docker or a binary, using SQLite or Postgres as storage, or use Convex Cloud.

## Option B: just Postgres, with your own auth

### Neon (or any managed Postgres)

**What it is.** [Neon](https://neon.com/docs/introduction) is serverless Postgres, now part of Databricks, with autoscaling, scale-to-zero, instant restore and database branching. It also offers a managed auth product built on Better Auth. The core engine is [open source under Apache 2.0](https://github.com/neondatabase/neon), but the repository documents running it locally for experiments, not production self-hosting.

**Best for.** Teams who use Supabase mostly as a database and are happy to pick their own auth library, file storage and API layer. Branching per pull request and scale-to-zero suit preview environments and spiky workloads.

**Trade-offs.** You assemble the rest yourself: auth, an S3-compatible bucket for files, realtime, and an API layer or ORM. More moving parts, each replaceable. RLS policies that call `auth.uid()` will need reworking.

**Licence and hosting.** Hosted service; engine open source. The same approach works with any managed Postgres from your cloud provider.

## Option C: keep Supabase, host it differently

Supabase itself is open source under Apache 2.0. If the product suits you, these routes keep your schema, RLS policies and client code as they are.

### Self-hosting Supabase

**What it is.** Supabase publishes an official [Docker Compose setup](https://supabase.com/docs/guides/self-hosting) that runs Postgres, Auth, the REST API, Realtime, Storage, Edge Functions and Studio on your own server.

**Best for.** Teams with ops experience who need full control, data in a specific place, or no vendor at all.

**Trade-offs.** You take on TLS, SMTP, backups, upgrades, monitoring and security. Self-hosted Studio manages one project per stack, and features such as branching, managed backups and point-in-time recovery aren't included. Our guide to [how to self-host Supabase](/guides/self-host-supabase) lists everything you take on.

**Licence and hosting.** Apache 2.0; runs anywhere Docker runs.

### Managed hosting of open-source Supabase (SupaHost)

**What it is.** [SupaHost](/pricing) runs the open-source Supabase stack on a cloud VM dedicated to your account. One instance holds many projects, each with its own database, Auth, Storage, API URL and keys, so supabase-js works unchanged. Pricing is a flat monthly fee per instance, with no charges per monthly active user, Realtime connection or function invocation.

**Best for.** People running several Supabase projects whose bill is mostly per-project compute on Supabase Cloud, and who don't want to operate servers themselves.

**Trade-offs.** All projects on an instance share one server. SupaHost is in public beta, with no SLA, no SOC 2, ISO 27001 or HIPAA, no read replicas, no connection pooler, no image transformations and no Edge Function deploys from the Supabase CLI. Storage files are not included in the daily database backups. See [SupaHost vs Supabase Cloud](/compare/supabase-cloud) for the full list.

**Licence and hosting.** Commercial managed service running open-source software. Your project uses standard Supabase Postgres, and you can export a pg_dump or your Storage files at any time.

### Staying on Supabase Cloud

For one or two production projects, or if you need compliance certifications, an SLA or read replicas, Supabase Cloud is often the right answer. See the [Supabase pricing guide](/guides/supabase-pricing-explained) and [pricing calculator](/supabase-pricing-calculator).

## Comparison table

| Option | Open source? | Self-hostable? | Postgres? | Best for |
|---|---|---|---|---|
| Firebase | No | No | Only via SQL Connect (Cloud SQL) | Mobile apps, Google Cloud teams |
| Appwrite | Yes (BSD 3-Clause) | Yes | Not by default; managed Postgres option | Broad self-hostable BaaS |
| Nhost | Yes (MIT) | Yes | Yes | Postgres with GraphQL |
| PocketBase | Yes (MIT) | Yes, single binary | No (SQLite) | Small apps, prototypes, internal tools |
| Convex | Source-available (FSL, becomes Apache 2.0) | Yes | No (own database; Postgres can be its storage) | Reactive TypeScript apps |
| Neon + your own auth | Engine yes (Apache 2.0) | Not documented for production | Yes | Database-first teams, preview branches |
| Self-hosted Supabase | Yes (Apache 2.0) | Yes | Yes | Full control, ops-capable teams |
| SupaHost | Runs open-source Supabase; service is commercial | Managed for you | Yes | Many Supabase projects at a flat price |
| Supabase Cloud | Yes (Apache 2.0) | n/a (hosted) | Yes | One or two projects, compliance needs |

## Summary

If you want a different data model or API style, choose from Option A: Convex for reactive TypeScript, Nhost for GraphQL on Postgres, Appwrite for a broad self-hostable platform, PocketBase for small and simple, Firebase for mobile and Google Cloud. If you only need a database, Neon or another managed Postgres gives you the most freedom, at the cost of wiring up auth and storage yourself.

If Supabase works and only the cost or hosting bothers you, keep it: self-host it, or use a managed host such as SupaHost, which trades some of Supabase Cloud's managed features for flat pricing across many projects. The calculator on [/migrate/supabase-cloud](/migrate/supabase-cloud) estimates the difference, and [how to move a Supabase project to another host](/guides/migrate-supabase-project) covers the move.

## FAQ

### What is the best open-source alternative to Supabase?
It depends on your app. Appwrite (BSD 3-Clause) has the broadest feature set, Nhost (MIT) keeps Postgres and adds GraphQL, and PocketBase (MIT) is the simplest to run. If you like Supabase itself, remember it is open source too and can be self-hosted.

### Is Firebase better than Supabase?
Neither is better in general. Firebase is strong for mobile apps and Google Cloud integration, but its main database is NoSQL. Supabase gives you Postgres with SQL and row level security, which suits relational data and teams who know SQL.

### Can I self-host Supabase instead of switching?
Yes. Supabase publishes an official Docker Compose setup. You become responsible for TLS, email, backups, upgrades and security, and some hosted features such as branching and point-in-time recovery aren't included.

### Which Supabase alternative is easiest to migrate to?
Anything that runs Supabase itself, self-hosted or managed, because your schema, RLS policies and supabase-js code stay the same. Moving to a plain Postgres host is next easiest for the data, but you'll replace auth and storage. Moving to Firebase, Appwrite or Convex means rewriting data access.

### Is Convex open source?
It's source-available under FSL-1.1-Apache-2.0: you can self-host it, but not offer it as a competing service until each release converts to Apache 2.0 after two years.