Open Source Firebase Alternatives: Licenses and Self-Hosting

The main open source Firebase alternatives are Supabase (Postgres), Appwrite (BSD 3-Clause), PocketBase (MIT, SQLite), Nhost (MIT, Postgres and Hasura), Parse Server (Apache 2.0) and Convex (FSL Apache 2.0, a fair-source license). All of them can run on your own servers, and most also sell a managed cloud. The real difference between them is not the feature list but the license terms, the database underneath and how much work self-hosting is once you have real users.

This guide is for teams who want an open source Firebase alternative for one of three reasons: to avoid lock-in, to keep data on infrastructure they control, or to cut costs by running the backend on their own machines. We also explain where a managed, non-open-source platform like StitchDB fits, since it speaks the same open APIs as one of these stacks.

#License and database at a glance

A note on Convex: FSL is a fair-source license. It allows most uses but not running a product that competes with Convex's hosted service, and each release converts to plain Apache 2.0 after two years. For almost every app team that is fine; for a hosting company it is not.

#What "self-hosting" actually means

Running docker compose up on a laptop is the easy 5%. The other 95% is the work Firebase did for you:

• Backups and restores. Nightly dumps are not enough for a production app. You want point-in-time recovery, and you want to have tested a restore.
• Upgrades. Each component has its own release cycle. Database major versions need planned upgrades.
• TLS, DNS and secrets. Certificates, key rotation, and keeping the service key off clients.
• E-mail delivery. Auth sends sign-up and reset e-mails. You need an SMTP provider and good sender reputation.
• Monitoring. Disk full, connections exhausted, slow queries, failed cron jobs.
• Scaling. Some of these stacks scale out; some (PocketBase) are single-server by design.

None of this is hard for an experienced ops person. It is a real ongoing cost for a two-person app team. Count it before you decide that self-hosting is cheaper.

#The open source options in detail

#Supabase

Supabase combines Postgres with PostgREST (REST from your schema), GoTrue (Auth), Realtime, Storage and Deno Edge Functions. The self-hosted version runs with Docker Compose, and the hosted version runs in 17 AWS regions worldwide.

Its biggest strength is that it is just Postgres. Your data model is tables, your access rules are row level security policies, and any Postgres tool works. The flip side: you are running several services plus Postgres, so self-hosting has more moving parts than a single binary.

#Appwrite

Appwrite is a BSD-licensed backend with Auth, Databases, Functions, Storage, Messaging and Sites, installed with a single docker run that launches a setup wizard. It exposes REST, Realtime, GraphQL and S3-compatible APIs and has SDKs for web, Flutter, iOS and Android.

Appwrite is the closest open source match to Firebase's developer experience: tables or schemaless documents behind one SDK, permissions per row, and functions in many runtimes. It is a good pick if your team is not SQL-first.

#PocketBase

PocketBase is one Go binary with SQLite, auth (e-mail and OAuth2), file storage on disk or S3, realtime subscriptions and an admin dashboard. You can extend it with Go or JavaScript hooks.

It is the lightest option by far. The PocketBase FAQ says it scales vertically on a single server and that there are no plans to support other databases; it suggests Litestream for replication. The README warns that full backward compatibility is not guaranteed before v1.0. For side projects, internal tools and small SaaS apps, those limits rarely matter.

#Nhost

Nhost bundles Postgres, Hasura's GraphQL engine, Auth, Storage and Node.js functions, MIT licensed, with a docker-compose example in the repository. If you want a GraphQL API with Hasura's role-based permissions and event triggers, Nhost gives you that in one package.

#Parse Server

Parse Server is the open source continuation of Parse, Apache 2.0 licensed, running on Node.js with MongoDB or PostgreSQL. It has a long history and SDKs for many platforms. It is a sensible choice if you already know the Parse object model; see Back4App and Parse alternatives for hosted options.

#Convex

Convex's backend, dashboard and CLI are open source under FSL. Self-hosted Convex stores data in SQLite by default and can point at Postgres or MySQL. You write queries and mutations in TypeScript, and clients update reactively.

#Where StitchDB fits (and where it does not)

StitchDB is not open source and has no self-hosted edition. If running the backend yourself is a hard requirement, pick one of the projects above.

What StitchDB offers instead is a managed platform built on open interfaces. A project speaks the same APIs as the open-source Supabase stack: PostgREST for REST, GoTrue-compatible Auth, the Storage API, Realtime channels and Deno Edge Functions with Deno.serve. The compatibility guide lists what works unchanged: supabase-js and the Dart, Swift, Kotlin, Python and C# libraries, RLS policies with auth.uid(), and standard Postgres tools.

That gives you a practical exit plan, which is the main thing many teams want from open source in the first place:

• Every plan can export the whole project as one archive: a pg_dump custom-format file, auth users with bcrypt password hashes, stored files by bucket, Edge Function source and settings.
• The dump restores into any Postgres 15 or newer:

tar -xf project.tar
createdb mydb
pg_restore --no-owner --no-acl -d mydb database.dump

• Because the APIs match the open-source stack, you could move the export to a self-hosted Supabase install and keep most of your app code.

The trade-offs are real: StitchDB runs only in EU data centers (Germany and Finland), it is a younger platform than the open source projects above, and you depend on one vendor for uptime. In return you skip the operations list above: backups with point-in-time recovery on every plan (24 hours on Free, up to 30 days on Enterprise), upgrades, TLS and e-mail delivery are handled for you. See Why StitchDB for the project model.

#How to choose

1. Must you run it on your own hardware? If yes, drop the managed-only options and choose between Supabase, Appwrite, Nhost, PocketBase, Parse and Convex.
2. SQL or documents? SQL: Supabase, Nhost, or Parse with Postgres. Documents: Appwrite, PocketBase collections, Convex, Parse with MongoDB.
3. How big will it get? One server forever: PocketBase is hard to beat. Growing team and data: pick a Postgres stack.
4. Who will operate it? If nobody on the team wants pager duty, a managed service on open APIs is usually the better deal, as long as you can export everything.
5. How will you develop locally? Self-hosted stacks usually run in Docker on your laptop too. StitchDB's CLI runs the whole stack as native processes with stitchdb start; see local development.

For a broader comparison that includes closed platforms, see the best Firebase alternatives.

#FAQ

#Is Supabase fully open source?

Supabase publishes its components as open source and documents self-hosting with Docker Compose. Some hosted-platform features are not part of the self-hosted setup, so check the docs for the features you need.

#What is the easiest open source Firebase alternative to self-host?

PocketBase: one binary and a data folder. The trade-off is single-server scaling and SQLite only.

#Is Convex open source?

Its backend is published under FSL Apache 2.0, a fair-source license that becomes Apache 2.0 after two years. You can self-host it, but not offer a competing hosted service.

#Is StitchDB open source?

No. StitchDB is a managed platform. It is compatible with the open-source Supabase client libraries and APIs, and every plan can export the full project in standard formats.

Want the open APIs without the operations work? Start a free StitchDB project.