Firebase helps teams launch applications without building the whole backend themselves. As those applications grow, teams may need a relational data model or backend services they can configure and run alongside existing infrastructure on AWS or GCP. They want that flexibility while keeping the Firebase features their application relies on and a simple development workflow.

Reasons to consider Firebase alternatives:

• Relational data and reporting need joins and constraints that are awkward to represent through Firestore documents and duplicated fields.
• More listeners, reads, writes, and function activity make usage costs harder to plan; budget alerts alone do not cap charges.
• New features need independently configured backend services or private access to infrastructure your platform team already runs.
• The backend needs to fit your existing cloud networking and IAM, or run on AWS alongside the rest of the company.
• Moving away means adapting Firestore SDK calls, Security Rules, realtime listeners, and offline behavior.
• As agents add features, permissions and business logic become harder to review across client code and separate backend functions.

Firebase alternatives at a glance

Encore: backend code with infrastructure under your control

Encore combines the simplicity of a managed backend platform with infrastructure in your own AWS or GCP account, defined through type-safe primitives in application code. Developers and agents work with services, APIs, databases, Pub/Sub, buckets, caches, cron jobs, and secrets, while platform teams control how those resources run. The application runs on standard cloud services and can be built as a Docker image for deployment outside the Encore platform.

Encore uses static analysis to read the API and resource declarations without running the code, building an application model of service dependencies, resource connections, and the IAM needed for supported resources.

Backend services can run alongside the Firebase features you keep, with Postgres and other supported resources provisioned in your AWS or GCP account. Sizing, scaling, networking, and regions are controlled through environment configuration, while developers define APIs and resource dependencies in application code. Logs, metrics, and tracing are integrated, and existing Terraform can continue managing shared or unsupported infrastructure.

Working with agents

~/orders — claude

Claude Code v2.1.180Opus 4.8 · Encore MCP connected~/orders

Infra from codereading the code…

SQLDatabaseorders · postgres

Topicorders · pub/sub

Bucketdeclared in code

not running yet

A database, bucket, Pub/Sub topic, or any other supported infrastructure resource is declared in the code that uses it. When an agent adds one:

• APIs, business logic, and resource dependencies can be reviewed in the same pull request, with generated clients providing typed access from the frontend.
• From the first encore run, the agent can test the change against local infrastructure, then check it end to end in an isolated preview environment on Encore Cloud, or in your own cloud account on Enterprise.
• The same application definitions drive local development, previews, and production, keeping services and resource dependencies consistent while capacity and cloud settings are configured per environment.
• The agent can use type errors, traces, and logs to find and fix failures, and test the authorization checks and business rules in the API before opening a pull request.
• Platform teams can configure separate processes per service for independent deployment and scaling, with Pub/Sub subscribers for asynchronous work and cron jobs for scheduled processing.
• Platform teams keep control of production configuration and credentials through their access controls, while developers work with application-level resources.

Cloud resources are billed directly in your account, with costs determined by the services and capacity your team configures, alongside Encore's platform fee.

Best for

Encore fits engineering teams moving beyond Firebase that need their backend in their own AWS or GCP account, with developers and agents building features while platform teams control the infrastructure.

You can move one API or background workload at a time while keeping Firebase Authentication, Storage, or Firestore in use. An Encore authentication handler can verify Firebase ID tokens, preserving the existing sign-in flow. Moving Firestore data to Postgres requires a relational schema and data transformation, with Security Rules translated into backend authorization checks. Offline sync and realtime listeners can stay in Firebase while the new APIs take on other operations.

See Coming from Firebase for the migration steps.

Supabase: Postgres with a backend service bundle

Supabase combines Postgres, authentication, storage, realtime, and Edge Functions. Tables, foreign keys, joins, and SQL transactions give teams a relational data model, while client SDKs provide access to the bundled services.

Working with agents

An agent can write schema migrations, RLS policies, client calls, and Edge Functions, then check them with Supabase's local development tools. The operation still spans application code and database policies, so testing needs to cover the access path used by the client as well as any elevated backend credentials.

Best for

Supabase fits teams that want Postgres while keeping a managed backend bundle. Firestore data and queries need to be reworked for SQL, and RLS replaces the database access rules used by Firebase clients. Self-hosting provides an ownership option with provisioning, security, backups, and scaling handled by your team. The managed offering has spend controls, with usage and capacity still determining the bill.

Firebase also has SQL Connect, so a relational database alone may not require leaving Firebase. Supabase is worth choosing when its Postgres and service APIs fit how you want to build the backend.

Appwrite: a backend bundle you can self-host

Appwrite provides authentication, databases, file storage, functions, and realtime APIs through client and server SDKs. You can use Appwrite Cloud or run the platform on infrastructure you control.

Working with agents

An agent can run backend function code in Docker with Appwrite's local development tools. Execution permissions, event triggers, and timeouts need to be checked against the deployed project or a self-hosted instance; the local function runner does not enforce them.

Best for

Appwrite fits teams that want a BaaS bundle they can operate themselves, with self-hosting putting updates, backups, monitoring, and scaling under their control. Moving from Firebase means adapting SDK calls, data access, and Security Rules to Appwrite's APIs and permissions. Appwrite Cloud keeps the managed service model if your team prefers to leave operations to the provider.

Convex: reactive backend functions in TypeScript

Convex puts backend operations in TypeScript queries, mutations, and actions, with query subscriptions that update connected clients as data changes. Collaborative applications can use those subscriptions without implementing their own sync logic.

// convex/documents.ts; imports omitted.
// Requires an identity provider and by_owner index.
// ownerId stores identity.tokenIdentifier.
export const list = query({
  args: {},
  handler: async (ctx) => {
    const identity = await ctx.auth.getUserIdentity();
    if (!identity) throw new Error("Unauthorized");
    return await ctx.db
      .query("documents")
      .withIndex("by_owner", (q) =>
        q.eq("ownerId", identity.tokenIdentifier))
      .collect();
  },
});

Working with agents

An agent writes TypeScript functions with validators and generated types, then checks them with npx convex dev, which syncs code to a development deployment. Convex also supports local deployments in beta, so the agent can run and inspect backend changes on its own machine.

Best for

Convex fits applications where realtime behavior is central and the team wants queries and mutations in TypeScript. Its query, mutation, and action model replaces Firestore SDK calls and Cloud Functions, so migration involves adapting data access, authorization, and client subscriptions. You can use the managed platform or self-host and operate the backend yourself.

PocketBase: a small backend on one server

PocketBase packages a SQLite database, authentication, file storage, an admin UI, and realtime subscriptions into a single executable you run on your own server.

Working with agents

An agent can start a local instance, exercise the APIs, and work with collection rules and migrations without a hosted development account.

Best for

PocketBase fits small apps that can run on one server and teams willing to manage it. Moving from Firestore means adapting document data to SQLite-backed collections, and the single-server architecture becomes a constraint if you need independently scaled services. Its documentation advises against production-critical use while compatibility changes can require manual migrations.

How to choose

The right choice comes down to what you need to change:

• Encore for a service-based backend in your AWS or GCP account, with infrastructure provisioning and an integrated workflow for developers and agents.
• Supabase for Postgres and a familiar BaaS workflow.
• Appwrite for a backend bundle your team can self-host.
• Convex for TypeScript backend functions and automatic query reactivity.
• PocketBase for a small backend that fits on one server.

An Encore service can take on the operations that need SQL, separate scaling, or access to private cloud infrastructure while Firebase continues handling sign-in, client sync, and mobile tooling. Moving each workload separately lets the team preserve the Firebase features the product still needs.

Start with the quickstart, or see Coming from Firebase for how the two can run together.