Supabase combines Postgres and backend services so teams can launch quickly, including through app builders like Lovable. As those applications grow, engineering teams need to understand and extend the backend, often with requirements that make running it in their own AWS or GCP account more attractive. They want more control over infrastructure and costs while keeping the speed of the initial build.

Reasons to consider Supabase alternatives:

• The prototype became production, and the engineering team now has to understand the schema, permissions, and integrations an app builder generated.
• Features need independently scaled services or workers that exceed the hosted Edge Function runtime limits and have to run elsewhere.
• Even with spend controls, planning costs takes more work as compute, storage, and data transfer grow.
• The backend needs to run in your own AWS or GCP account, within the networking, IAM, and data residency requirements your team already manages.
• Moving away means untangling platform-specific client calls, authentication, storage policies, and realtime subscriptions.
• As agents add features, it becomes harder to follow a change through the backend and verify both its behavior and its permissions.

Supabase 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.

When a backend needs to move beyond hosted Supabase into your own AWS or GCP account, the platform team controls sizing, scaling, networking, and regions through environment configuration. Developers keep declaring the resources their features need in application code. Encore provisions supported resources with integrated logs, metrics, and tracing, while 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 Supabase that need their backend in their own AWS or GCP account, with developers and agents building features while platform teams control the infrastructure.

Adoption can start with one API or background workload while Supabase keeps providing Postgres, Auth, Storage, and Realtime. An Encore authentication handler can validate Supabase tokens, so the existing sign-in flow stays in place. If you move the database later, its application schema and data transfer with standard Postgres tools, while client calls and access policies are adapted to the new APIs.

See Coming from Supabase for the migration steps.

Firebase: managed services for mobile and web apps

Firebase combines authentication, databases, storage, functions, and hosting with mobile tools such as Crashlytics and Remote Config. Its Firestore database supports realtime listeners and offline client access, making it a good fit for apps that need to stay useful without a connection.

// With an initialized Firestore client:
const documents = query(
  collection(db, "documents"),
  where("ownerId", "==", userId),
);
onSnapshot(documents, (snapshot) => {
  renderDocuments(snapshot.docs.map((doc) => doc.data()));
});

Working with agents

An agent can generate client calls, functions, and Security Rules and test them with the Local Emulator Suite. Permissions live across rules for client access and IAM for server access, so checking a feature means following both paths. Functions can also call Google Cloud services beyond the Firebase bundle, with their permissions and configuration managed separately.

Best for

Firebase fits teams that want stronger mobile tooling or Firestore's sync model and are comfortable with Google's ecosystem and usage billing. Moving from Supabase to Firestore requires restructuring relational data and queries. Its Postgres-backed SQL service preserves a relational model, with schemas and operations defined through its own connector tooling.

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 Supabase means adapting queries and policies to Appwrite's database APIs. If hosting is the only thing you want to change, self-hosting Supabase keeps more of the existing application intact.

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 document model and function runtime replace Supabase's SQL queries and Edge Functions, so migration involves adapting both data access and backend behavior. 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 Supabase means adapting the data model to SQLite, 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.

Neon: keep Postgres, build the backend separately

Neon provides managed Postgres with branching and scale-to-zero. If the database is the part of Supabase you want to keep, it lets you choose application hosting and backend services separately.

import { neon } from "@neondatabase/serverless";

const sql = neon(process.env.DATABASE_URL!);
// userId is supplied by backend authentication.
const documents = await sql`
  SELECT id, name FROM documents
  WHERE owner_id = ${userId}
`;

Working with agents

An agent can check queries and schema changes against an isolated database branch paired with an application preview, before applying the migration to production.

Best for

Neon fits teams that want managed Postgres and choose the rest of their backend separately. Neon Auth can provide authentication, while application hosting, file storage, and background processing come from other services. Supabase Data API calls and storage or realtime integrations need their own migration alongside the database.

How to choose

The right choice comes down to what your backend needs next:

• Encore for teams that need their backend in their own AWS or GCP account without managing all the infrastructure wiring themselves.
• Firebase for mobile tooling, offline sync, and Google's ecosystem.
• Appwrite for a BaaS bundle with a self-hosting option.
• Convex for reactive TypeScript functions and collaborative applications.
• PocketBase for a small self-hosted app that fits on one server.
• Neon for managed Postgres alongside a separately built backend.

An Encore service can take on the APIs or background workloads that need to run in your cloud account while Supabase continues providing Auth, Storage, or Realtime. The rest of the backend can move as your requirements change.

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