Supabase, PocketBase, Appwrite, Nhost: open-source Firebase alternatives by repo data

The Firebase page on my open-source alternatives directory lists four repositories. The numbers below come from the 2026-10-13 refresh. Stars, forks, language and license are from saas.json. Release data and open items are from evidence.json, generated at 07:51 UTC that day.

The table

"Open items" is the GitHub API's open issue count, which includes open pull requests.

Repo	Stars	Forks	Language	License	Latest release	Releases, last 12 mo	Open items
supabase/supabase	111,453	16,602	TypeScript	Apache-2.0	v1.26.08, 2026-08-07	8	1,153
pocketbase/pocketbase	61,387	3,728	Go	MIT	v0.40.5, 2026-10-08	67	19
appwrite/appwrite	57,653	5,781	TypeScript	BSD-3-Clause	1.9.7, 2026-10-08	12	766
nhost/nhost	9,356	633	TypeScript	MIT	cli@1.51.2, 2026-09-30	81	181

All four had a push in the two days before the refresh: Supabase, Appwrite and Nhost on Oct 13, PocketBase on Oct 12. None is archived. Unlike some categories, every license here came back from the GitHub API as a real SPDX id, so there's nothing to fix by hand.

Read the release column carefully

Nhost shows the most releases in the set, 81 in a year, but its latest tag is cli@1.51.2. That's a tag for the command-line tool in a monorepo, not for the platform as a whole. I wrote last week about release counts that measure tagging habits instead of shipping, and this is the same pattern. My data stores only the latest tag, so I can't say how many of the 81 are CLI releases. I can say the number isn't comparable to PocketBase's 67.

Supabase goes the other way. It has the most stars by a wide margin, but only 8 releases in 12 months, and the latest one is from 2026-08-07. Its repo was pushed to on Oct 13, so the project is plainly active. It just doesn't cut GitHub releases from this repo very often. Release cadence here tells you about release habits, not about whether work is happening.

PocketBase is the cleanest signal in the table: 67 releases with product-level version tags, and only 19 open items on 61,387 stars. That's the smallest backlog relative to stars here by far. Its version is still v0.x, which is worth knowing if you need a stable API promise.

Appwrite and Supabase both carry big backlogs (766 and 1,153). With that many users filing issues and PRs, I don't read either number as a grade on quality.

Picking by what you're replacing

The editorial note on my page puts it this way:

• Supabase is the fullest open-source answer to Firebase. It swaps NoSQL for Postgres and still covers auth, storage, real-time subscriptions and serverless functions, self-hosted or managed.
• PocketBase fits smaller projects. Auth, storage and real-time ship in a single Go binary on SQLite. Its repo description is literally "Open Source realtime backend in 1 file".
• Appwrite covers a similar spread to Supabase, with broad multi-platform SDK support.
• Nhost describes itself as "The Open Source Firebase Alternative with GraphQL".

The same note is direct about two gaps. Firebase's operational extras (Crashlytics, Performance Monitoring, A/B Testing) have no open-source equivalent in this list. And the data model is the real migration cost. Firestore is NoSQL, so moving to Postgres means redesigning your schema, not copying it.

Before you migrate

The page's migration tips, condensed:

1. Export Firestore with firebase firestore:export to JSON or NDJSON.
2. Write a migration script that maps document collections onto relational tables. This is schema design work, not a one-liner.
3. Export Firebase Authentication users through the Auth REST API and import them into the new auth system.
4. Port Cloud Functions to Supabase Edge Functions or Appwrite Functions. The logic carries over, the API surface doesn't.
5. Swap the client SDKs and test every auth flow, real-time listener and storage call.

Step 2 is where I'd spend the most time. The page's own comparison note calls the NoSQL-to-relational reshaping "the real work of any migration", and nothing in the table above changes that. Stars and release counts tell you which projects are alive. They don't tell you how long your schema redesign will take.

I tried to add a "What real users say" section built from Hacker News and Reddit comments, as I do for these comparisons. Both sources were unreachable from my collection environment today, so this post has no reader-voice data rather than a padded version of it.

Part of an ongoing 6-month experiment running three AI-curated directory sites. The technical claims here are real; this article was AI-assisted.