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.

The short answer: choose Firebase for mobile tooling and offline sync, Appwrite for a self-hostable backend bundle, Convex for reactive TypeScript applications, PocketBase for a small single-server app, or Neon when you mainly want managed Postgres. Choose Encore when the next step is a service-based backend whose infrastructure runs in your AWS or GCP account.

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.

Key features

• Type-safe APIs and service-to-service calls, with generated clients for frontend applications.
• PostgreSQL databases, object storage, Pub/Sub, caches, cron jobs, and secrets declared alongside the code that uses them.
• Local infrastructure for development and isolated preview environments for pull requests.
• Deployment to Encore Cloud or supported services in your AWS or GCP account, with integrated tracing, logs, and metrics.

~/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.

Good to know

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()));
});

Key features

• Firestore and Realtime Database provide client SDKs, realtime updates, and offline behavior for mobile and web applications.
• Firebase Authentication, Cloud Storage, Cloud Functions, Hosting, Crashlytics, and Remote Config cover a broad app-development workflow.
• The Local Emulator Suite supports local testing across several Firebase services.

Client access is controlled through Security Rules, while server access and Google Cloud integrations use IAM. Reviewing a feature therefore means checking both permission paths. Cloud Functions can also call services beyond the Firebase bundle, with their configuration managed separately.

Good to know

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.

Key features

• Authentication, permissions, databases, file storage, Functions, Messaging, and Realtime are available through client and server SDKs.
• Appwrite Cloud provides the managed option; the open-source stack can also run on infrastructure you control.
• Current database options include TablesDB and DocumentsDB, plus native PostgreSQL and MySQL on dedicated infrastructure.

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

Good to know

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();
  },
});

Key features

• TypeScript queries, mutations, actions, validators, and generated types keep backend operations in one programming model.
• Reactive queries update subscribed clients when their underlying data changes.
• Built-in scheduling, file storage, search, and integrations with external identity providers cover common application needs.

npx convex dev syncs backend functions to a development deployment and updates generated types as the schema changes. Convex also supports local deployments in beta for running and inspecting the backend on your own machine.

Good to know

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.

Key features

• SQLite-backed collections, authentication, file storage, an admin dashboard, and realtime subscriptions ship in one executable.
• Collection rules provide record-level access control, while migrations keep schema changes in source control.
• Go and JavaScript hooks let an application extend the generated APIs without introducing a separate service for every customization.

The complete backend can run locally, so developers can exercise its APIs and work with collection rules and migrations without a hosted development account.

Good to know

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}
`;

Key features

• Standard Postgres compatibility preserves SQL, drivers, migration tools, and much of an existing Supabase database schema.
• Database branches provide isolated copies for development and previews without duplicating all underlying storage.
• Compute can autoscale and scale to zero; connection pooling is available for serverless and high-concurrency workloads.

Queries and schema changes can be checked against an isolated database branch paired with an application preview before the migration reaches production.

Good to know

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.

Related comparison and migration guides

• Encore compared with Supabase
• Migrate from Supabase to AWS
• Migrate from Supabase to Google Cloud
• Neon serverless Postgres guide