If you want relational data and SQL with a Firebase-style backend around it, Supabase is the most direct swap: a full PostgreSQL database with auth, storage, realtime and functions, open source under Apache 2.0. Nhost offers the same idea with a GraphQL API, and Neon suits teams that mainly want serverless Postgres. For open source and self-hosting, Appwrite covers the most Firebase features, and PocketBase is the simplest to run on one server. If you like Firebase's realtime, non-SQL model and only want to change vendor, look at Convex; if you are moving to AWS, AWS Amplify.
Firebase is Google's app platform: authentication, hosting, Cloud Functions, storage and two NoSQL databases, Cloud Firestore and the Realtime Database. Firestore stores documents in collections, works offline through its SDKs, and its Enterprise edition offers a MongoDB-compatible API. Firebase now has a relational option too, SQL Connect (formerly Data Connect), which puts a GraphQL-defined API in front of Cloud SQL for PostgreSQL.
The reasons people look for alternatives fall into four groups. Some points are documented by Google; the rest are our editorial reading, not a survey.
- SQL and relational data. Firestore is a document database, so joins, constraints and ad hoc SQL reporting are not part of it (editorial). SQL Connect adds PostgreSQL, but through Cloud SQL on the pay-as-you-go Blaze plan, with access defined as GraphQL operations.
- Open source and lock-in. Firebase is a proprietary Google service. Teams who want the option to inspect, fork or move their backend prefer an open source stack (editorial).
- Self-hosting. Firebase cannot be run on your own servers, which matters for data residency or on-premises requirements (editorial).
- Predictable pricing. The Spark plan has daily quotas (for Firestore, 50,000 reads and 20,000 writes a day on the pricing page checked in October 2026), and Blaze is pay as you go. Since 3 February 2026, Cloud Storage for Firebase requires the Blaze plan, even though no-cost usage still applies on Blaze, so many projects now need a billing account. Firebase documents that spend caps cover only AI Logic, App Hosting, Cloud Functions and Extensions, and that budget alerts elsewhere do not pause services.
Each entry below says which of these it addresses. For the most common head-to-head, see Supabase vs Firebase. If you are weighing Supabase itself against other options, our Supabase alternatives guide covers the same platforms from the other side.
Quick picks
Every project is a full PostgreSQL database, with auth, storage, realtime and edge functions around it, under an Apache 2.0 licence.
MIT licensed stack of PostgreSQL and Hasura GraphQL with auth, storage and functions, hosted or self-hosted.
BSD 3-Clause licensed and self-hosted with Docker, with auth, databases, storage, functions, messaging and realtime.
One MIT-licensed executable with embedded SQLite, auth, realtime, file storage and an admin UI, on a server you control.
A reactive, document-relational database where queries are TypeScript functions and clients update automatically.
How we chose
We considered Supabase, Nhost, Neon, Appwrite, PocketBase, Convex and AWS Amplify, plus staying on Firebase with SQL Connect. To be included, a product had to be actively developed or sold in 2026, provide a database plus at least some of Firebase's surrounding services (or be a database a Firebase team would realistically move to), and publish its plans, licence and self-hosting position on an official page.
For each one we recorded its data model (SQL or not), licence, whether it can be self-hosted, and how its free tier and billing work, as shown on official pages on 7 October 2026. We describe pricing models rather than quoting prices, because they change often and several are usage-based; check the linked pricing pages before deciding. None of this comes from our own use of the platforms.
The order is not a ranking: SQL-based platforms come first, then open source backends with their own data models, then non-SQL managed platforms.
At a glance
| Platform | Price | Data model | Open source | Self-host | Main trade-off |
|---|---|---|---|---|---|
| Supabase | Freemium | PostgreSQL (SQL) | Yes, Apache 2.0 | Yes (Docker Compose, with feature gaps) | Free projects pause after 1 week inactivity |
| Nhost | Freemium | PostgreSQL via GraphQL | Yes, MIT | Yes (Docker Compose) | GraphQL-first; smaller community |
| Neon | Freemium (usage-based) | PostgreSQL (SQL) | Core is Apache 2.0 | Not as the managed platform | Backend features are new; usage-based bills |
| Appwrite | Freemium | Tables and documents; native PostgreSQL and MySQL on Cloud | Yes, BSD 3-Clause | Yes (Docker) | Native SQL databases launched September 2026 |
| PocketBase | Free (self-hosted) | SQLite (embedded) | Yes, MIT | Yes (only option) | Pre-1.0; one server only |
| Convex | Freemium | Document-relational, TypeScript queries | Source available (FSL, becomes Apache 2.0) | Yes | No SQL |
| AWS Amplify | Pay as you go (AWS Free Tier) | DynamoDB via AppSync; can connect MySQL or PostgreSQL | Tooling Apache 2.0 | No (AWS services) | Costs spread across AWS services |
Supabase
Addresses: SQL, open source, self-hosting, and partly pricing. Supabase gives every project a full PostgreSQL database rather than an abstraction, with direct connections, extensions such as pgvector, PostGIS and pg_cron, and Row Level Security so clients can query tables directly and safely. Around it are authentication, file storage, realtime subscriptions to database changes, edge functions and the Studio dashboard with a SQL Editor. The main repository is Apache 2.0 licensed.
Its plans are Free, Pro, Team and Enterprise. As listed on 7 October 2026, the Free plan allows 2 active projects with a 500 MB database and 50,000 monthly active users. Paid plans have a monthly base fee plus usage, and the Pro plan's Spend Cap blocks overage charges on most usage items, though not compute. See Supabase vs Firebase.
- Free projects are paused after one week of inactivity.
- Supabase documents that each project has its own Postgres server and adds compute cost, and the Spend Cap does not cover compute.
- Self-hosted installs are a single project without branching, managed point-in-time recovery or analytics.
- Firestore's offline cache in the mobile SDKs has no drop-in equivalent in a Postgres backend, so offline behaviour needs planning (editorial).
Nhost
Addresses: SQL, open source, self-hosting and predictable pricing. Nhost is an MIT-licensed backend that pairs PostgreSQL with the Hasura GraphQL Engine, plus its own authentication and storage services and Node.js functions. Its pricing page lists real-time subscriptions, event triggers and role-based authorisation on all plans. It runs on the hosted platform, locally through its CLI, or self-hosted with Docker Compose.
Plans are Starter (free), Pro, Team and Enterprise, each with a fixed monthly base and usage billed above quotas. It suits Firebase teams that liked subscribing to live data and want a relational schema underneath, with GraphQL as the client API.
- The free Starter plan is one project with a 1 GB database, paused after one week of inactivity.
- Client access is through GraphQL and Hasura permissions rather than Firebase-style SDK calls, which is a new model to learn.
- Smaller project and community than Supabase or Firebase.
Neon
Addresses: SQL, and partly open source. Neon is serverless PostgreSQL with storage separated from compute, database branching and scale to zero; its core repository is Apache 2.0 licensed. Neon is now owned by Databricks and also offers Managed Better Auth, a PostgREST-compatible Data API secured by JWT and Row Level Security, functions and object storage.
Its plans are Free, Launch and Scale. The Free plan needs no credit card and, as listed on 7 October 2026, gives each project 1 GB of storage and 100 compute-unit hours a month, with compute suspended after 5 minutes of inactivity. Paid plans are metered hourly with no monthly minimum. It suits teams moving off Firestore to a relational database who already have, or prefer to keep, auth elsewhere. See Supabase vs Neon and Neon vs PlanetScale.
- Its backend services beyond the database are newer than Firebase's or Supabase's.
- Usage-based billing is not a fixed monthly cost, which does not help if predictability is your main reason for leaving Firebase.
- Neon's documentation describes no offline cache comparable to Firestore's, so offline behaviour is up to your app (editorial reading of the docs).
Appwrite
Addresses: open source, self-hosting, predictable pricing and, on its cloud, SQL. Appwrite is BSD 3-Clause licensed and covers authentication, databases, storage, serverless functions, messaging (email, SMS and push notifications), realtime and Sites for front-end hosting, which maps closely onto the Firebase product list. Its TablesDB offers typed columns, rows and relationships, and DocumentsDB offers schemaless JSON-style documents.
Since September 2026 Appwrite Cloud can also provision dedicated, native PostgreSQL and MySQL databases that you connect to directly, in all six of its cloud regions. Appwrite's pricing page offers usage-based billing or fixed monthly tiers for reserved resources, and the Free plan allows 2 projects.
- The native PostgreSQL and MySQL databases are new, launched in September 2026.
- The Free plan is limited to 2 projects, and services such as function executions or uploads are disabled when limits are exceeded.
- Self-hosting the full platform means running and updating several containers yourself.
PocketBase
Addresses: open source, self-hosting, predictable pricing and SQL storage. PocketBase is an MIT-licensed backend in a single executable, with an embedded SQLite database, realtime subscriptions, email/password and OAuth2 authentication, file storage (local or S3) and an admin dashboard, plus SDKs for front-end frameworks including Flutter. The current version on its site is 0.40.4.
Because you run it on your own server, the cost is whatever that server costs. Its FAQ positions it for small and midsize applications such as SaaS, mobile API backends and intranets.
- Pre-1.0: the project states full backward compatibility is not guaranteed before v1.0.0.
- Scales vertically on a single server only, and supports SQLite only.
- No official hosting; backups, updates and uptime are your responsibility.
Convex
Addresses: lock-in (partly) and self-hosting, not SQL. Convex is a document-relational database: JSON-like documents in tables with relations. Queries are TypeScript functions rather than SQL, and they are reactive, so subscribed clients update when the data changes. The backend is under the Functional Source License 1.1, converting to Apache 2.0 two years after each release, and can be self-hosted with SQLite or Postgres among the documented options.
Plans are Free and Starter, Professional (priced per developer) and Business and Enterprise. It suits Firebase users whose main attraction was live data in the client and who are comfortable writing their backend in TypeScript.
- No SQL, so it does not address the most common reason for leaving Firebase.
- Source available rather than open source until each release converts to Apache 2.0.
- Professional plan pricing is per developer.
AWS Amplify
Addresses: a change of cloud vendor, and SQL if you bring your own database. Amplify Gen 2 defines a backend in TypeScript with Git branch-based environments, using Apache 2.0 licensed tooling. Amplify Data creates an API powered by AWS AppSync and connected to Amazon DynamoDB, and can also connect to existing MySQL or PostgreSQL databases. Auth, storage and functions use Cognito, S3 and Lambda.
Amplify has its own free tier and pay-as-you-go pricing, and the underlying services are billed separately. It suits teams whose company already standardises on AWS rather than Google Cloud.
- The default database, DynamoDB, is NoSQL like Firestore; relational data needs a separate MySQL or PostgreSQL database.
- Pay-as-you-go billing across several AWS services is no more predictable than Firebase's Blaze plan.
- Proprietary AWS services; not self-hostable.
When to stay with Firebase
Stay if your data fits documents and your app depends on Firestore's offline cache and mobile SDKs; few alternatives here document an equivalent. If the only gap is relational data, check Firebase SQL Connect first: it gives you Cloud SQL for PostgreSQL with generated, type-safe SDKs while keeping Firebase Auth and the rest of your project. Its pricing page lists a no-cost allowance of SQL Connect operations each month and a free trial period for Cloud SQL, on the Blaze plan.
If cost control is the worry, set budget alerts and the spend caps Firebase does offer, and review which services they cover. If you do leave, plan the data migration first: moving from documents to tables means designing a relational schema, and our guides on SQL vs NoSQL and MongoDB vs PostgreSQL explain the trade-offs.
Frequently asked questions
What is the best SQL alternative to Firebase?
Supabase is the most direct: a full PostgreSQL database with auth, storage, realtime and functions, under an Apache 2.0 licence. Nhost (PostgreSQL with GraphQL) and Neon (serverless PostgreSQL) are the other SQL-based options here. See Supabase vs Firebase.
Is there an open source Firebase alternative I can self-host?
Yes. Supabase (Apache 2.0), Appwrite (BSD 3-Clause), Nhost (MIT) and PocketBase (MIT) can all be self-hosted. Appwrite covers the widest set of Firebase-like services; PocketBase is the simplest to run.
Does Firebase support SQL now?
Yes, through Firebase SQL Connect (formerly Data Connect), which uses Cloud SQL for PostgreSQL with a GraphQL-defined API and generated SDKs. Cloud SQL is available on the pay-as-you-go Blaze plan.
Can I cap my Firebase bill?
Only partly. Firebase documents spend caps for AI Logic, App Hosting, Cloud Functions and Extensions; for other services, budget alerts notify you but do not pause usage.
Which Firebase alternative has the most predictable cost?
Self-hosting PocketBase or Appwrite ties cost to your own server. Among managed services, Nhost and Supabase have fixed base plans with usage on top, and Appwrite offers fixed monthly tiers for reserved resources. Usage-based services such as Neon, AWS Amplify and Firebase Blaze vary with traffic.
Sources
- Firebase pricing
- Cloud Firestore documentation
- Firebase SQL Connect
- Firebase: Cloud Storage requires the Blaze plan
- Firebase: avoid surprise bills
- Supabase pricing
- Supabase database documentation
- Supabase cost control (Spend Cap)
- Supabase GitHub repository (licence)
- Nhost pricing
- Nhost GitHub repository (licence)
- Neon pricing
- Appwrite pricing
- Appwrite GitHub repository (licence)
- PocketBase FAQ
- Convex: how Convex works
- Amplify Data documentation
- AWS Amplify pricing
Checked October 2026.
How we research these guides: our editorial method.