Open Source Firebase Alternatives

Supabase assembles the pieces of a backend around a Postgres database rather than a proprietary store. You get a database, authentication, generated APIs, file storage and functions, and the database underneath stays an ordinary Postgres you can query, migrate and take elsewhere.

The platform is a combination of separate open source tools instead of one monolith. PostgREST turns the schema into a REST API, pg_graphql exposes a GraphQL one, an Elixir service broadcasts inserts, updates and deletes over websockets, GoTrue handles JWT-based sign-ups and sessions, and a storage API manages files in S3 with Postgres enforcing the permissions.

That combination is what an application developer actually consumes.

• Generated APIs: REST, GraphQL and realtime subscriptions follow the schema as it changes.
• Auth: sign-up, login and session management, with authorization pushed down into the database.
• Functions: database functions for logic close to the data, edge functions for everything else.
• Vectors: an AI and embeddings toolkit sitting beside the relational data.
• Modular clients: libraries for JavaScript, Flutter and more, each underlying service also having a standalone client.

The stated policy is to adopt an existing tool whenever a suitably licensed one exists and to build and open source the missing piece otherwise. You can sign up for the hosted platform without installing anything, self-host the same stack, or develop locally against it. Documentation, a dashboard and several community support channels are maintained alongside the code.

PocketBase packs the parts most small applications need into one Go binary you can drop onto a server. There is no separate database process, no auth service and no storage layer to wire together first.

You can take it two ways. Downloading a prebuilt executable and running the serve command gives a working backend immediately, with a JavaScript VM plugin enabled for extending it, while importing the Go package instead lets you add your own routes and business logic and still ship a single portable executable.

What the binary already contains covers most of a backend.

• Embedded SQLite: the database travels with the application and supports realtime subscriptions.
• Users and files: authentication and file management are built in rather than bolted on.
• Admin dashboard: a web interface for managing your collections and records comes included.
• REST-ish API: a straightforward HTTP surface that the official SDKs wrap for you.
• Client SDKs: JavaScript for browser, Node and React Native, Dart for web, mobile and desktop.

Building from source needs a recent Go toolchain, and static binaries compile without cgo for a long list of targets across Linux, macOS, FreeBSD and more. The maintainers warn that the project is still under active development and backward compatibility is not guaranteed before version 1.0.

Appwrite brings backend infrastructure and web hosting into one place so teams stop stitching a stack together from separate services. It targets web, mobile and AI applications, cutting the repetitive backend work that stands between an idea and a shipped product, and it runs either as a managed cloud or on infrastructure you control.

The platform is organized as products that share one console and one set of APIs.

• Auth: email and password, SMS, OAuth, anonymous sessions and magic links, with session management and multi-factor verification.
• Databases: structured storage with databases, tables and rows, plus querying, pagination, indexing and relationships.
• Storage: uploads and downloads with encryption, compression and transformations for media and assets.
• Functions: serverless compute in isolated runtimes, fifteen of them supported, triggered by events or on a schedule.
• Messaging: email, SMS and push notifications for engagement, alerts and transactional workflows.
• Sites: hosting for web apps with custom domains, server-side rendering, Git integration and previews.

Self-hosting is containerized. One docker run command with the Docker socket mounted installs the server, after which the console opens in a browser; from there you can move to Docker Compose, Kubernetes, Docker Swarm or Rancher. Public compose files and environment variable documentation cover production setups.

Client and server SDKs wrap the APIs for the usual languages, and one-click deployments exist for hosted providers.

Building a web app normally means gluing a database to an API layer to a client cache. Convex removes those seams, an open source reactive database aimed at web app developers and explicitly at the LLMs writing code beside them, where data fetching and business logic are written as pure TypeScript with strong consistency.

The product is three things at once. A database, a place to write server functions, and client libraries that keep the front end current as the underlying data changes, which is what makes live-updating apps straightforward to build and scale.

A few things are worth knowing before committing to the open source build.

• Repository layout: Rust crates hold the backend, with local_backend acting as the application server, while TypeScript packages carry the public and internal SDKs.
• Test suites: the team's well designed test frameworks, randomized testing included, are not part of the open source offering.
• Platform maturity: Linux and macOS are the most thoroughly tested, Windows much less so.
• Telemetry: self-hosted builds send an anonymous beacon carrying a random deployment id, migration version, git revision and uptime, which a flag disables.

Self-hosting includes most of the cloud product, dashboard and CLI included, running through Docker or a prebuilt binary and working with Postgres, SQLite and hosts such as Neon, Fly.io, Vercel and Netlify. If you build from source rather than following the guide, change the instance secret and admin key away from the repository defaults before exposing anything.

Instant is a database you use directly from the client. The usual sequence of standing up servers, caches, ORMs and endpoints, then writing stores, selectors and mutators, then finally painting a screen, collapses into writing a relational query in the shape of the data you want.

The premise behind it is that most of the work UI engineers do is a database problem in disguise. With a database on the client, stores and local caches stop being your concern. Because every query is multiplayer by default, stateful servers do too. Because the store supports rollback, optimistic updates come for free.

The architecture that makes this work is documented rather than hidden.

• Triple store: user data is kept as triples in one multi-tenant Postgres database.
• InstaQL: a relational query language shaped much like GraphQL, resolved by a datalog query engine.
• Sync server: written in Clojure, it tails the Postgres write-ahead log to detect novelty and invalidate affected queries.
• Client cache: recent queries persist to IndexedDB on the web and AsyncStorage in React Native.
• Permissions: every read and write passes a permission system powered by the Google CEL library.

Ephemeral state such as cursors and who is online rides alongside durable data, so presence needs no separate service. SDKs exist for JavaScript, React and React Native, and a barebones realtime chat app takes about a dozen lines.

The multi-tenant setup lets a free hosted tier run without pausing, and both the client and server can be run locally with instructions in their own directories.

Nhost is a backend platform assembled entirely from open source software you could run yourself anyway. A PostgreSQL database sits under an instant GraphQL API from Hasura, with authentication, file storage and serverless functions around it, so a front-end team gets a working back end without writing one.

Each piece stays a separate open source service rather than a proprietary bundle. Auth and storage are maintained in the same repository, functions run on Node.js in JavaScript or TypeScript, and the SQL and GraphQL layers are the ones you already know how to debug.

Three ways of running it are documented, each suited to a different stage of a project.

• Hosted platform: sign in, create an app and start building against it immediately.
• Local development: the CLI creates a local environment that tracks database migrations and Hasura metadata.
• Self-hosting: the whole stack runs from an example docker compose file, since every component is open source.
• Client library: the JavaScript client signs a user in and sends GraphQL requests in a handful of lines.
• Frontend agnostic: quickstarts cover Next.js, React and React Native, and any framework works against the API.

The CLI installs through Homebrew, a shell script, Nix or any JavaScript package manager, and three commands, login, init and up, bring an environment online. Full documentation and framework quickstarts sit alongside the repository for the parts this summary skips.

bknd is a backend system that implements the primitives almost any application needs, data, authentication, media and workflows, behind a visual admin interface. It spares you from deploying several separate services, and from writing the same authentication and database plumbing again.

Everything is built on the WinterTC Minimum Common Web Platform API, which is why the same code runs across so many runtimes. All four feature areas are modular and opt-in, and infrastructure access is adapter-based with direct access to the underlying drivers, so an abstraction never becomes the reason something is impossible.

The package splits into four import paths, each with its own job.

• bknd: the backend itself with a full REST API and the adapters, served from Node, Bun, workerd or a route inside a React framework.
• bknd/ui: admin components that drop the complete management interface into a single React page.
• bknd/client: a type-safe TypeScript SDK and React hooks, including SWR wrappers that handle query invalidation for you.
• bknd/elements: ready-made React components for login, registration and media uploads.
• MCP server: a built-in server, client and UI for controlling the backend from an AI assistant.

Runtimes include Node 22 and later, Bun, Deno, the browser, Cloudflare Workers and Pages, Vercel, Netlify and AWS Lambda. Data can live in SQLite through LibSQL, Cloudflare D1 or SQLocal, or in Postgres through Supabase, Neon or Xata, with files on S3-compatible storage, R2, Cloudinary or disk. A minimal API is about 300 kB gzipped. The project is pre-1.0, so backward compatibility is not yet guaranteed.

undb is a no-code platform that doubles as a backend for applications. Tables are managed through a browser interface, data sits in SQLite, and the same project can be one file on a laptop or a service running for a whole team, which removes the usual jump between a spreadsheet and a real backend.

Because the storage engine is SQLite, the whole thing stays light. Bun can package it into a single binary, or it runs as a Docker container listening on one port with a mounted volume for the data directory. A one-click Render deployment and a hosted cloud version cover the other end of the range.

Table management goes well past storing rows.

• Views: kanban, gallery, calendar and pivot layouts over the same underlying table.
• Forms: collect entries from people who never see the table behind them.
• Formula fields: calculated columns in the style of Excel or Airtable.
• REST API: an OpenAPI-described interface, which is what makes it usable as a backend service.
• Playground mode: try the product without setting anything up first.
• Progressive deployment: begin as a single local file and grow into a cloud stack later.

Local development needs Bun and a clone, with dependencies installed and a dev server started in two commands, or a Docker Compose file for the same result. The project calls itself private and local first, which is the appeal for anyone wanting Airtable-shaped tooling without their data leaving the building.

Built specifically for mobile, desktop, and web applications, Aptabase offers itself as an alternative to Firebase and Google Analytics. It removes the tradeoff where getting usage numbers means adopting an identifier-driven tracking stack and the compliance work that trails behind it.

Instead of using unique identifiers, Aptabase prioritizes user privacy and collects minimal usage data, focusing on monitoring sessions, which is what keeps it compliant with GDPR, CCPA, and PECR. A built-in dashboard covers the essential metrics with no configuration to grasp how an app is being used. The project says it is highly inspired by Plausible, which does the same job for website analytics.

An SDK exists for most places an app gets written.

• Apple platforms: a Swift SDK for iOS and the rest of the Apple ecosystem.
• Android and cross-platform: Kotlin for Android, with React Native and Flutter alongside.
• Desktop shells: Electron and Tauri plugins, plus .NET MAUI and NativeScript.
• Game engines: SDKs for Unreal Engine and Unity Engine.
• Web: a JavaScript SDK for web apps, and a wiki guide for writing your own when a platform is missing.

A managed cloud runs the service for you, with updates and patches handled by the people who wrote it, while self-hosting is free and leaves maintenance to you, documented in a separate repository. The server is AGPLv3, so changes to it must be shared, while the SDKs are MIT and carry no such condition once embedded in an app.