← Blog
Engineering

Firebase alternatives: match the backend you need

Yura Oak
Yura OakAugust 21, 2026

Choose a Firebase alternative by the Firebase services you need to replace. Supabase and Nhost belong on a shortlist for a PostgreSQL-based backend. Appwrite offers an integrated backend product. PocketBase can suit a small self-hosted project. Hosting your own API on Lizard is another approach, but it does not automatically replace Firebase Authentication, security rules or realtime client behaviour.

This comparison comes from Lizard. We checked the linked documentation on 9 September 2026. Start with architecture and migration effort, then compare the bill.

Firebase is more than a database

An app may use Firestore, Realtime Database, Authentication, Storage, Functions, Hosting and messaging in different combinations. Each has its own API and cost model. Firebase pricing lists those products separately.

Exporting documents solves only part of a migration. The client may depend on realtime listeners, offline behaviour and security rules that the new system expresses differently. Authentication also includes identity providers, account recovery and sessions, not just a users table.

Make a list of SDK calls in your application. Use it to define the replacement contract before picking a vendor.

A shortlist by backend model

OptionWhy to evaluate itWhat needs review
SupabasePostgreSQL with an integrated backend workflowSQL schema, access policies and client API changes
AppwriteAuth, databases, storage, functions and realtime featuresAPI compatibility and cloud versus self-hosted operation
ConvexA reactive backend approachIts data and function model compared with your existing code
PocketBaseAn embedded SQLite backend in a compact applicationProduction requirements, upgrades and recovery
NhostDatabase, GraphQL, auth and storage in one backend productGraphQL model, permissions and deployment requirements
AWS AmplifyAn application backend built around AWS servicesAWS identity, resources and the resulting bill
Your own API and PostgreSQLControl over the server-side applicationBuilding auth, authorization and realtime behaviour you need

Read the primary product documentation for Supabase, Appwrite, Convex, Nhost and Amplify before treating a feature label as equivalent behaviour.

When PostgreSQL is the reason to move

A relational database can fit data that benefits from joins, transactions and explicit constraints. It also changes how you model and query documents that were designed for Firestore.

Start with the queries your app must answer. Map collections, nested values and identifiers to a schema, then check reads and writes with real data. Do not assume a mechanical conversion of every document produces a useful relational model.

If you choose your own API, Managed Postgres provides the database on Lizard. Your application still implements its endpoints and access checks. Supabase or Nhost may be a closer fit when you want an integrated backend API rather than building one yourself.

When self-hosting is the reason to move

Self-hosting gives you control over deployment and data placement. It also makes backups, upgrades, monitoring and recovery part of your operating plan.

PocketBase combines an embedded SQLite database with auth, file handling and realtime features. Its documentation warns that backward compatibility is not guaranteed before version 1.0 and advises caution for production-critical applications. Evaluate that stated limit against your project rather than presenting a small binary as an automatic production replacement. PocketBase documentation.

For any self-hosted backend, test restoration from backup and the upgrade path before depending on it. A process that starts successfully has not yet demonstrated data recovery.

Compare the complete cost model

Firestore billing can include document operations, storage and network use. Another product may charge by database compute, users, function usage or a base plan. Those units measure different things. Firestore billing documentation.

Record the same workload for each option: active users, reads, writes, stored data, file downloads, function execution and required environments. Add the plan you need for backups or other essential features. Use Firebase, Supabase, Appwrite and Lizard pricing as applicable.

Avoid calculating savings by comparing a database's entry plan with the whole Firebase bill. Also include development work: replacing client SDK calls and security rules can cost more than a small monthly hosting difference.

A migration plan that tests permissions

  1. Inventory the Firebase products, SDK calls, security rules and identity providers in use.
  2. Design the replacement data model and the access rules for each user role.
  3. Import a test dataset. Check counts, identifiers, timestamps and representative application queries.
  4. Test access as an anonymous user, a normal user and an administrator. Include denied reads and writes.
  5. Test sign-in, sign-out, password recovery, file access and realtime updates where used.
  6. Plan the final write transition, client release and rollback. Old mobile or browser clients may continue calling the old API.

On Lizard, a custom backend can use Managed Redis where appropriate and Managed Object Storage for files. Storage access policy must match the sensitivity of those files; do not assume a newly provisioned bucket is private.

FAQ

Is Lizard a direct Firebase replacement? Lizard can host your backend and data services. It does not automatically supply the Firebase client API, auth flows or security rules. Choose it when you want to run that server-side application.

Which alternative is closest to Firebase? It depends on which Firebase products you use. Compare actual APIs, auth, file access and realtime behaviour rather than selecting by a feature count.

Can I keep Firebase Authentication and move the database? You can design a backend that verifies the existing identity tokens. Check token verification and authorization carefully; accepting an identity is not the same as granting access to every record.

Will PostgreSQL remove all usage charges? No. The host still charges under its own plan for compute, storage, traffic or other services. The meter changes; the need to estimate the workload remains.

What is the most important migration test? Confirm that users can access exactly the records and files they should, and no others. Data import success alone does not prove correct permissions.

Build with AI. Ship with Lizard.

You don't need a platform team to go live. Your whole cloud, one CLI command away.

Try for free

No credit card required

We use cookies for essential site functionality and analytics. See our Cookie Policy.