Open source backend as a service platforms

Three kinds of backend

Every tool here covers the same core: a database that client apps can query through an API or SDK, sign-up and login, rules that decide which rows or documents each user may read and write, file uploads and live updates. They differ mainly in how they are built.

• Multi-service platforms. Supabase, Appwrite, Nhost and InsForge run several services (database, auth, storage, functions, a dashboard) side by side, usually with Docker Compose. They come closest to Firebase in breadth, and all four offer an official cloud. Supabase, Nhost and InsForge sit on PostgreSQL; Appwrite exposes its own database API and stores data in PostgreSQL, MariaDB or MongoDB, chosen at install time.
• Single-binary backends. PocketBase (Go) and TrailBase (Rust) ship as one executable with an embedded SQLite database and an admin UI. They are the easiest to run and back up, but scale up on one server rather than across many, and neither has a hosted service.
• Framework-style backends. Parse Server and Kuzzle are Node.js servers you configure and extend in code. Parse Server works with MongoDB or PostgreSQL and can be mounted in an Express app; Kuzzle stores documents in Elasticsearch and speaks HTTP, WebSocket and MQTT, which suits IoT projects. PocketBase and TrailBase can also be used as libraries in Go or Rust.

Data model and authorization

The biggest decision is the database. Firebase’s Firestore stores nested documents in collections; most open source options are relational. Supabase, Nhost and InsForge let you write SQL against standard Postgres, which keeps the data portable, but Firestore data has to be remodeled into tables. Parse Server on MongoDB and Kuzzle on Elasticsearch stay closer to a document model.

Because clients talk to the database directly, the authorization layer matters as much as the database. Supabase and InsForge use Postgres row-level security policies keyed to the user’s token. Nhost declares role-based permissions per table in its GraphQL metadata. PocketBase uses filter expressions per collection, TrailBase SQL access rules per API, Appwrite permissions per resource with optional row-level security, and Parse Server class-level permissions plus per-object ACLs. Check that you can express your rules before you commit, and that new tables are locked by default.

What to check before you choose

1. Self-hosting effort. A single binary with a data directory is a very different job from a dozen containers. Supabase documents a minimum of 4 GB RAM for its Docker stack, and Appwrite asks for 2 CPU cores and 4 GB RAM.
2. Self-hosted versus cloud features. Self-hosted Supabase runs one project and lacks branching, managed backups and point-in-time recovery. Appwrite’s self-hosted edition matches its cloud more closely. Nhost and Supabase treat self-hosting as community-supported.
3. Functions. Deno edge functions (Supabase, InsForge), container-based runtimes in several languages (Appwrite), Node.js (Nhost), WebAssembly (TrailBase), JavaScript hooks (PocketBase) or code inside the server process (Parse Server Cloud Code, Kuzzle).
4. Migration from Firebase. Appwrite’s console has a migration wizard for Firebase Auth users and top-level Firestore documents. Supabase provides guides and tools for Auth (including Firebase’s password hash parameters), Firestore and Storage. The other projects have no official importer. Firebase exports users with its own modified scrypt hashes, so check that the target can verify them or plan for password resets.
5. License of the whole stack. The main repositories here are under OSI licenses, but check the pieces around them: the Parse Dashboard admin UI has its own non-OSI license, Kuzzle needs Elasticsearch, and some InsForge features rely on third-party cloud services.
6. Hosted options. Supabase, Appwrite, Nhost and InsForge run official clouds with free plans. Kuzzle’s company sells a managed IoT platform. Parse Server is hosted by third-party providers, and PocketBase and TrailBase are self-hosted only.

Where the data lives

Firebase sets locations per product and per resource rather than per project, and Cloud Functions run in us-central1 unless you choose a region. AWS Amplify deploys into your own AWS account, but only on AWS services. Self-hosting any of the projects above puts the database on servers you pick, though backups, upgrades and security patches become your job.

Projects not listed

Some well-known backends are not open source and are left out. The Convex backend is under the Functional Source License (FSL-1.1-Apache-2.0), Directus uses the Monospace Sustainable Core License, which forbids competing commercial use, and SurrealDB is under the Business Source License. Instant (InstantDB) is Apache-2.0, but its team has announced it is joining OpenAI and Instant Cloud will shut down on 31 August 2027, so its future maintenance is unclear and it is not listed for now. Hasura’s GraphQL engine is an API layer rather than a full backend; it appears here as part of Nhost.