Appwrite Alternatives in 2026

Appwrite is an open-source backend that bundles auth, databases, storage, functions and realtime behind its own APIs and client SDKs, and teams can use the managed cloud or self-host it as a set of Docker containers. It starts to hurt when the backend grows past what fits in Appwrite Functions, when the team wants plain SQL against the data, or when the backend has to run inside the company's own AWS or GCP account, because none of those fit neatly inside the bundle. This article compares the options teams usually look at next, which are Encore, Supabase, Firebase, PocketBase, Nhost and Convex.

Reasons teams look for Appwrite alternatives:

• Business logic outgrows Appwrite Functions and needs proper services, workers and queues.
• The team wants plain SQL and standard database tooling instead of a database that is only reachable through platform APIs.
• Self-hosting means operating a whole platform, including upgrades, data migrations between releases, backups and scaling.
• The backend has to run inside an existing AWS or GCP account and follow its networking, IAM and data residency rules.
• Client permissions, function triggers and timeouts have to be tested against a deployed project, because the local function runner does not enforce them.

Appwrite alternatives at a glance

Encore: backend code with infrastructure in your own cloud

Encore combines backend code and infrastructure for projects that have grown past the point where Appwrite functions wrapped around platform APIs are enough, so you write the services and APIs in TypeScript or Go and declare the Postgres databases, Pub/Sub topics, buckets, cron jobs and secrets in the same code, encore run starts all of it locally (Postgres runs in Docker), and a deploy creates the same resources in your own AWS or GCP account.

An existing Appwrite login can keep working while the backend moves, because the client sends the JWT from account.createJWT() and an Encore auth handler checks it by calling Appwrite before any authenticated endpoint runs, and those endpoints can then query a Postgres database declared in the same service.

import { api, APIError, Gateway, Header } from "encore.dev/api";
import { authHandler } from "encore.dev/auth";
import { getAuthData } from "~encore/auth";
import { SQLDatabase } from "encore.dev/storage/sqldb";
import { Account, Client } from "node-appwrite";

interface AuthParams { authorization: Header<"Authorization">; }
interface AuthData { userID: string; email: string; }

// Checks the Appwrite JWT by calling GET /account with it.
export const auth = authHandler<AuthParams, AuthData>(async ({ authorization }) => {
  const client = new Client()
    .setEndpoint(process.env.APPWRITE_ENDPOINT ?? "https://cloud.appwrite.io/v1")
    .setProject(process.env.APPWRITE_PROJECT_ID ?? "")
    .setJWT(authorization.replace(/^Bearer /, ""));
  try {
    const user = await new Account(client).get();
    return { userID: user.$id, email: user.email };
  } catch {
    throw APIError.unauthenticated("invalid Appwrite JWT");
  }
});

export const gateway = new Gateway({ authHandler: auth });

// Postgres runs in Docker with `encore run` and on RDS or Cloud SQL when deployed.
const db = new SQLDatabase("notes", { migrations: "./migrations" });

interface Note { id: number; body: string; }

export const listNotes = api(
  { expose: true, auth: true, method: "GET", path: "/notes" },
  async (): Promise<{ notes: Note[] }> => {
    const { userID } = getAuthData()!;
    const rows = db.query<Note>`SELECT id, body FROM notes WHERE owner_id = ${userID}`;
    const notes: Note[] = [];
    for await (const row of rows) notes.push(row);
    return { notes };
  },
);

Key features

• Services, Postgres databases, Pub/Sub, buckets, cron jobs and secrets are declared next to the code that uses them.
• encore run starts the services and their infrastructure locally, and the local development dashboard shows a trace of each request, so a change can be tested end to end before it is deployed.
• A deploy provisions the resources in your own AWS or GCP account, and the app has no runtime dependency on Encore.

Good to know

Encore does not include a hosted user directory or sign-in UI, so teams connect an identity provider through an authentication handler, and that provider can stay Appwrite Auth while the rest of the backend moves. There is also no automatic realtime sync to clients, so teams either build it with streaming APIs or keep Appwrite Realtime for it. Migrating is a code change, and since adoption can be incremental most teams start with one API or background job.

See how to migrate Appwrite to AWS.

Supabase: a BaaS built on Postgres

Supabase combines Postgres with authentication, storage, realtime and Edge Functions, so you get a relational model with tables, foreign keys, joins and SQL transactions, and the client SDKs talk to the bundled services.

Key features

• It is plain Postgres, so SQL, migrations and standard tools work as usual.
• Row-Level Security controls what clients can read and write.
• The Supabase CLI runs a local development stack.

Good to know

Supabase is the closest swap for teams that want a bundle like Appwrite with SQL at the center, where Appwrite permissions become RLS policies and client calls move to Supabase's SDK. Like Appwrite it can be self-hosted, which comes with the same operational responsibility.

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, and Firestore supports realtime listeners and offline client access.

Key features

• Firestore and Realtime Database come with client SDKs and offline behavior.
• Firebase Authentication, Cloud Storage, Cloud Functions and Hosting cover the rest of the backend.
• The Local Emulator Suite runs these services locally for testing.

Good to know

Firebase fits teams that care most about mobile tooling and offline sync and are comfortable with Google's ecosystem and usage billing. It is only available as a managed service, so teams that chose Appwrite because they could self-host it would lose that option.

PocketBase: a small backend on one server

PocketBase

PocketBase packages a SQLite database, authentication, file storage, an admin UI and realtime subscriptions into a single executable.

Key features

• Collections, auth, file storage, the admin dashboard and realtime all ship in one binary.
• Collection rules handle record-level access control.
• Go and JavaScript hooks can extend the generated APIs.

Good to know

PocketBase is much lighter to self-host than Appwrite and fits small apps on one server well, although that single-server design becomes the limit once you need services that scale independently. Its documentation also advises against production-critical use while compatibility changes can still require manual migrations.

Nhost: Postgres with a GraphQL API

Nhost

Nhost is a Postgres backend platform with an instant GraphQL API, authentication, storage and serverless functions in JavaScript or TypeScript, and it can also run your own containers.

Key features

• Postgres is exposed through a GraphQL API with realtime subscriptions.
• Auth, storage with a CDN and serverless functions are included.
• The CLI runs the full stack locally, and deploys are git-based.

Good to know

Nhost fits teams that want Postgres and GraphQL out of the box, and since permissions are defined on the GraphQL layer, Appwrite permission rules have to be rewritten there. Its ecosystem is smaller than that of Supabase or Firebase.

Convex: reactive backend functions in TypeScript

Convex puts backend operations in TypeScript queries, mutations and actions, and its query subscriptions update connected clients when the data changes.

Key features

• Queries, mutations and actions are written in TypeScript with generated types.
• Reactive queries push updates to subscribed clients.
• Scheduling, file storage and search are built in.

Good to know

Convex fits apps where realtime behavior is central, but data moves into Convex's document model and logic into its function runtime, so migrating from Appwrite means reworking both. It can run on the managed platform or be self-hosted.

How to choose

• Encore if the backend needs real services, queues, and cron jobs in your own AWS or GCP account.
• Supabase for a BaaS like Appwrite with Postgres at the center.
• Firebase for mobile tooling and offline sync inside Google's ecosystem.
• PocketBase for a small self-hosted app on one server.
• Nhost for Postgres with an instant GraphQL API.
• Convex for reactive TypeScript apps.

Teams usually move one part at a time, so an Encore service can take over the APIs and background jobs that have outgrown Appwrite Functions while Appwrite keeps handling auth and storage. The quickstart walks through a first service.

Related comparison and migration guides

• Migrate from Appwrite to AWS
• Migrate from Appwrite to Google Cloud
• Supabase alternatives
• Backend as a Service in 2026