Supabase bundles a Postgres database, authentication, file storage, edge functions, and real-time subscriptions into one platform. That's a lot of functionality for $25/month, and for early-stage projects the speed is hard to beat. You get a working backend in minutes.

The tradeoffs show up later. Pricing jumps as your database grows and API calls increase. You can tune some Postgres parameters via CLI now, but VPC peering isn't available (PrivateLink exists on the $599/month Team plan, limited to database connections), and infrastructure-level control remains limited compared to running your own instances. Compliance requirements in healthcare or finance often demand infrastructure in accounts you own. And Supabase's client libraries and auth system create coupling that makes migration harder the longer you stay.

Most Supabase alternatives are other BaaS platforms with the same fundamental model: managed infrastructure you don't control, usage-based pricing you can't predict, and varying degrees of vendor lock-in. This guide covers options that actually change the tradeoff, from infrastructure you own to open-source self-hosting to different architectural models entirely.

Supabase Alternatives: An Overview

Encore

Encore has two parts. The open-source framework lets you declare infrastructure in TypeScript or Go: databases, Pub/Sub, cron jobs, object storage, caching, secrets. It handles local development with real Postgres, Pub/Sub, and distributed tracing out of the box. Encore Cloud takes that same code and provisions managed cloud services in your own AWS or GCP account, with CI/CD, preview environments, and observability.

The distinction matters because the framework is free and doesn't require Encore Cloud. You can use it locally and deploy however you want. encore build docker generates standard containers. Encore Cloud is what replaces Supabase's managed backend: instead of running on a shared platform, your database is an RDS instance in your account, your file storage is an S3 bucket you own, and your message queue is SNS+SQS with your IAM policies.

Here's what a service with a database, file storage, and event publishing looks like:

import { api } from "encore.dev/api";
import { SQLDatabase } from "encore.dev/storage/sqldb";
import { Bucket } from "encore.dev/storage/objects";
import { Topic } from "encore.dev/pubsub";

// Provisions RDS on AWS, Cloud SQL on GCP. Runs real Postgres locally.
const db = new SQLDatabase("documents", { migrations: "./migrations" });

// Provisions S3 on AWS, GCS on GCP.
const uploads = new Bucket("uploads", { versioned: true });

// Provisions SNS+SQS on AWS, GCP Pub/Sub on GCP.
const docEvents = new Topic<DocumentEvent>("doc-events", {
  deliveryGuarantee: "at-least-once",
});

export const uploadDocument = api(
  { method: "POST", path: "/documents", expose: true, auth: true },
  async (req: UploadRequest): Promise<Document> => {
    const doc = await db.queryRow`
      INSERT INTO documents (owner_id, name, size)
      VALUES (${req.ownerId}, ${req.name}, ${req.size})
      RETURNING *`;
    await uploads.upload(
      `${doc!.id}/${req.name}`, req.data, { contentType: req.contentType }
    );
    await docEvents.publish({ docId: doc!.id, action: "created" });
    return doc!;
  }
);

The infrastructure declarations are the only Encore-specific parts. Everything inside them is standard TypeScript with standard npm dependencies. The Encore surface is small, and the rest of your codebase works the same way it would in any Node.js project.

This provisions RDS, S3, SNS+SQS, and Fargate on AWS, or Cloud SQL, GCS, GCP Pub/Sub, and Cloud Run on GCP. All in your account, visible in your cloud console.

Why teams choose Encore over BaaS

The core difference is infrastructure ownership. On Supabase, your database shares resources with other tenants, your backups follow their schedule, and a platform incident affects you even when your code is fine. On Encore, your application runs on standard AWS or GCP services with no runtime dependency on Encore's servers. If Encore Cloud itself went down, your running applications would keep serving traffic. New deploys would wait, but production stays up.

Billing is also structurally different. Supabase's Pro plan starts at $25/month per project but scales unpredictably with database size, bandwidth, and function invocations. Running equivalent infrastructure on your own AWS account with reserved instances can cut costs by 50-70% at scale, and you get native access to savings plans, budget alarms, and spending limits.

Key features

• Infrastructure from code: databases, Pub/Sub, cron, caching, object storage, secrets
• Deploys to your own AWS or GCP account
• No runtime dependency on Encore Cloud once deployed
• Built-in distributed tracing, logging, and metrics
• Preview environments for every PR
• Type-safe service-to-service calls with generated clients
• encore build docker for standard Docker images
• MCP server for AI agent integration

AI agent integration

Because infrastructure is declared in the same code that AI agents read and write, an agent can look at a single service file and understand that it uses a Postgres database, publishes to a topic, and stores files in a bucket. That's enough context to generate a new endpoint that queries the same database or a subscriber that processes events from the same topic, without the agent needing to find and interpret separate infrastructure config.

Encore also provides an MCP server and editor rules that give agents access to database schemas, distributed traces, and the full service architecture. An agent can verify its own work against real request data and generate code that follows existing patterns.

Good to know

Encore supports TypeScript and Go. Instead of Supabase's client-side SDK pattern where database queries run from the frontend, you write server-side endpoints with full control over authorization, validation, and business logic. That's a shift if you're used to calling supabase.from("documents").insert(...) directly, but it's the same development model every backend framework uses, and it's what most teams adopt once their application grows past early prototyping. If you want to leave, encore build docker generates standard containers and your cloud resources stay in your account.

Try Encore

See the quick start guide to get started, or book a 1:1 intro for a walkthrough. If you're ready to migrate from Supabase to AWS or GCP, the migration guide walks through the process step by step, including database export, auth migration, and DNS cutover.

Firebase

Firebase is Google's BaaS and the oldest player in this space. It predates Supabase by nearly a decade and offers a broader set of services: Firestore, Authentication, Cloud Storage, Cloud Functions, Hosting, Remote Config, A/B testing, and Crashlytics. If you're building a mobile app with Google services, Firebase is deeply integrated into that ecosystem.

The biggest difference from Supabase is the database. Firestore is a NoSQL document store, not Postgres. If your data model is relational, with joins, transactions across tables, and complex queries, moving to Firebase means restructuring how you store and access data. For document-oriented data or real-time syncing to mobile clients, Firestore is well-suited. For anything that looks like a relational schema, it's a step backward.

import { initializeApp } from "firebase/app";
import { getFirestore, collection, addDoc } from "firebase/firestore";

const app = initializeApp(config);
const db = getFirestore(app);
const docRef = await addDoc(collection(db, "documents"), {
  ownerId: userId,
  name: "report.pdf",
  createdAt: new Date(),
});

Key features

• Firestore with real-time sync and offline support
• Firebase Auth with 10+ built-in providers plus SAML/OIDC via Identity Platform
• Cloud Functions (Node.js, Python)
• Firebase Hosting with global CDN
• Crashlytics, Analytics, Remote Config
• Generous free tier (Spark plan)

Good to know

Firebase runs entirely on Google Cloud infrastructure you don't control. The vendor lock-in is higher than Supabase because Firestore's data model and query language are proprietary. Migrating away from Firebase means rewriting your data layer, not just changing a connection string. Pricing is usage-based across reads, writes, storage, and function invocations, which can produce surprising bills under load. Firebase solves the "I want more services than Supabase" problem well, but it doesn't change the ownership or lock-in tradeoffs.

Appwrite

Appwrite is an open-source BaaS that you can self-host on your own server or use as a managed cloud service. The feature set mirrors Supabase closely: database, auth, storage, functions, and real-time, with a similar client SDK pattern. The pitch is that you get Supabase-like functionality with the option to run it on infrastructure you own.

Appwrite uses MariaDB under the hood instead of Postgres. If you're coming from Supabase and your application depends on Postgres-specific features like pgvector, jsonb operators, or CTEs, you'll need to adjust your queries.

import { Client, Databases, ID } from "appwrite";

const client = new Client()
  .setEndpoint("https://your-appwrite.example.com/v1")
  .setProject("your-project-id");

const databases = new Databases(client);
const doc = await databases.createDocument(
  "main-db", "documents", ID.unique(),
  { ownerId: userId, name: "report.pdf" }
);

Key features

• Self-hosted on any Docker-compatible server
• Database, auth, storage, functions, and real-time
• 15+ SDKs across client and server (Web, Flutter, iOS, Android, Node, Python, Go, etc.)
• Role-based access control built in
• Managed cloud option (Appwrite Cloud)
• Active open-source community (55k+ GitHub stars)

Good to know

Self-hosting gives you infrastructure ownership, but you take on the operational work: updates, backups, monitoring, scaling, and security patching. Appwrite has had security vulnerabilities disclosed over the years, which is expected for actively maintained open-source software but highlights the surface area of running your own platform. If you don't want to self-host, Appwrite Cloud has the same shared-infrastructure tradeoffs as Supabase. Appwrite is the right choice if you want the BaaS development model and are willing to manage the hosting yourself.

Convex

Convex is a reactive backend platform that takes a different approach from both Supabase and traditional backends. Instead of SQL queries against a database, you write TypeScript functions that Convex runs on its own infrastructure. The database is a document store with automatic real-time subscriptions: when data changes, connected clients update immediately without you writing any sync logic.

The development model is closer to writing serverless functions than managing a database. You define queries, mutations, and actions as TypeScript files, and Convex handles execution, caching, and real-time delivery.

// convex/documents.ts
import { mutation, query } from "./_generated/server";
import { v } from "convex/values";

export const create = mutation({
  args: { name: v.string(), ownerId: v.string() },
  handler: async (ctx, args) => {
    return await ctx.db.insert("documents", {
      name: args.name,
      ownerId: args.ownerId,
      createdAt: Date.now(),
    });
  },
});

export const list = query({
  args: { ownerId: v.string() },
  handler: async (ctx, args) => {
    return await ctx.db
      .query("documents")
      .withIndex("by_owner", (q) => q.eq("ownerId", args.ownerId))
      .collect();
  },
});

Key features

• Automatic real-time updates on all queries
• TypeScript-first with end-to-end type safety
• ACID transactions
• Scheduled functions and cron jobs
• File storage
• Built-in full-text search

Good to know

Convex went open-source in 2024 and added self-hosting support in early 2025, so you can run it on your own infrastructure using Docker. The self-hosted option stores data in SQLite or Postgres, though the deployment and operational tooling is newer and less mature than the managed cloud. The database uses a custom document model and doesn't support SQL, so migrating away means rewriting your data access layer. If real-time reactivity is the core requirement and you're comfortable with a non-SQL data model, Convex delivers on that well. If you need Postgres compatibility or standard cloud services, it's the wrong direction from Supabase.

PocketBase

PocketBase is an open-source backend packaged as a single Go binary. You download it, run it, and get a SQLite database, authentication, file storage, and a real-time API. No Docker, no dependencies, no configuration files. For solo developers and small projects, the simplicity is unmatched.

PocketBase has grown to over 44,000 GitHub stars and earned a following among indie developers and hobbyists who want a self-contained backend they can deploy to a $5 VPS.

Key features

• Single binary, zero external dependencies
• SQLite database with a REST API
• Built-in auth with OAuth2 support
• File storage
• Real-time subscriptions via SSE
• Admin dashboard included

Good to know

PocketBase runs on a single server with SQLite. There's no horizontal scaling, no managed cloud option, and no support for Postgres. If your application needs multiple servers, high availability, or handles more data than SQLite can manage comfortably, PocketBase isn't the right tool. It's designed for projects that fit on one machine and stay there. For prototyping and personal projects it's excellent. For production workloads that outgrew Supabase, moving to another single-server architecture doesn't solve the underlying problem.

Neon

Neon is serverless Postgres. It's not a Supabase replacement in the sense that it doesn't offer auth, storage, or edge functions. What it does offer is a Postgres database with branching, scale-to-zero, and a generous free tier. If the main thing you use from Supabase is the database, and you're building your backend with a framework, Neon gives you a better Postgres experience without the rest of the BaaS bundle.

Database branching is Neon's standout feature. You can create instant copies of your database for each PR or test run, similar to how Git branches work for code. This is useful for preview environments and testing migrations against production data without risk.

// Standard Postgres connection — works with any framework
import postgres from "postgres";

const sql = postgres(process.env.DATABASE_URL);
const docs = await sql`
  SELECT * FROM documents WHERE owner_id = ${ownerId}
`;

Key features

• Serverless Postgres with scale-to-zero
• Database branching for previews and testing
• Point-in-time restore
• Postgres 17 with pgvector support (Postgres 18 in preview)
• Connection pooling built in
• Generous free tier (0.5 GB storage, 100 compute-hours/month with scale-to-zero)

Good to know

Neon solves one piece of the Supabase puzzle well. You still need to build or choose solutions for auth, file storage, background jobs, and deployment yourself. That's either liberating or exhausting depending on your team. Neon pairs naturally with backend frameworks: you get serverless Postgres from Neon and the rest of the backend stack from the framework. With Encore, you can use Neon as your database provider and still get infrastructure-from-code for everything else. For teams that want to keep Postgres but ditch the BaaS model, Neon is the starting point, and a framework fills in the rest.

How to choose

Teams leaving Supabase are usually trying to solve one of three problems: they want more infrastructure control, they want to reduce costs at scale, or they've hit the limits of the BaaS development model. The right alternative depends on which problem matters most.

Firebase and Appwrite Cloud are lateral moves. They offer a similar BaaS experience with different strengths: Firebase has more services and tighter mobile integration, Appwrite has a broader SDK ecosystem and an open-source option. If you like the BaaS model and your frustration with Supabase is about specific missing features rather than the model itself, these are worth evaluating, though the shared-infrastructure and lock-in tradeoffs that pushed you away from Supabase remain.

Appwrite self-hosted gives you infrastructure ownership, but you take on everything that Supabase handled: updates, backups, security patches, scaling, monitoring. For teams with the ops capacity to manage it, it's a legitimate path. For teams that left Supabase specifically to avoid operational complexity, it trades one set of problems for another.

Convex is the right choice if real-time reactivity is central to your application and you're comfortable trading Postgres and infrastructure control for a simpler real-time development model. It solves a different problem than Supabase, not the same problem differently.

PocketBase works well for solo projects and prototypes that fit on a single server. If your application outgrew Supabase, it likely needs more than SQLite on one machine can offer.

Neon gives you better Postgres without the BaaS bundle. If you're building a backend with a framework and just need a database, Neon's branching and scale-to-zero make it a strong choice for the database layer.

Across all of these: Firebase and Appwrite keep the BaaS model, Convex trades SQL for reactivity, and Neon handles the database but not the rest of your backend. Encore is the only option here that gives you a complete backend with infrastructure you own.

Encore is the most complete Supabase replacement for teams moving to production infrastructure. Your backend deploys to standard AWS or GCP services in your own account, with native billing, no shared failure domains, and no runtime dependency on Encore's servers. You write TypeScript, declare your infrastructure in code, and the platform handles provisioning, networking, and observability. If you've outgrown BaaS and want to own your infrastructure without hiring a DevOps team, Encore is the most direct path from Supabase to production-grade AWS or GCP.

Related resources

• How to Migrate from Supabase to AWS
• How to Migrate from Supabase to GCP
• What is Infrastructure from Code?
• Encore Quick Start