The best Appwrite alternatives in 2026

Appwrite's pitch is easy to like: everything a backend usually needs — authentication, a database, file storage, serverless functions, realtime subscriptions — as one open-source product you can run yourself or buy managed. For a small team that would otherwise spend three weeks on auth alone, that is a real saving.

The reasons people go looking for alternatives are consistent, and they are mostly not about missing features. I'm Ajay, I build PandaStack, which appears on this list as an unbundling option rather than a competing backend platform — I will be clear about that distinction.

The four reasons people actually leave

• The database. Appwrite's database is its own abstraction with its own query API. Teams that want to write SQL, use an ORM they already know, or point an analytics tool at production find this to be the sharpest edge.
• Operational weight. Self-hosted Appwrite is a multi-container system with a database, a cache and workers behind it. That is more to keep alive than a single binary, and more than some teams signed up for.
• Only needing one piece. A surprising number of Appwrite installs exist because someone needed auth. Running an entire backend platform to avoid writing a session table is a trade worth revisiting.
• Scale characteristics. The bundle is optimised for coherence, not for the specific hot path your product turned out to have.

1. Supabase

The obvious first comparison and usually the right one. Same bundle — auth, database, storage, functions, realtime — but built on ordinary Postgres, which changes the calculus completely. Every SQL tool, ORM, migration framework and BI product works against it without an adapter, and the exit path if you ever leave is a pg_dump rather than a data migration project.

Self-hosting Supabase is heavier than self-hosting Appwrite, not lighter — it is a larger collection of services. And row-level security as the authorisation model is powerful but genuinely takes time to learn well; RLS policies are where most Supabase security incidents come from.

2. PocketBase

The opposite answer, and an excellent one for the right project. A single Go binary with SQLite inside it that gives you auth, a database with an admin UI, file storage and realtime subscriptions. Deployment is copying a file to a server. Backup is copying a file back.

The constraint is honest and structural: one binary, one machine, SQLite. That is fine — genuinely fine — for a very large number of applications, and it is not the answer if you need horizontal scaling or expect a team of ten to be extending the backend in Go.

3. Nhost

Postgres plus Hasura plus auth and storage, open source, managed or self-hosted. The distinguishing piece is GraphQL as the primary interface, generated from your schema, with permissions declared against it.

Worth a look specifically if your clients want GraphQL and you were going to build a layer for it anyway. If you do not want GraphQL, the main thing that differentiates it from Supabase is working against you.

4. Directus

Comes at it from the content-management direction: point it at an existing SQL database and get a REST and GraphQL API, an admin interface and a permissions model over tables you already designed. That last part is the key difference — it wraps your schema instead of owning it.

Auth and realtime are less central than in a purpose-built BaaS. Strongest when the application is substantially content and editorial workflow rather than transactional logic.

5. Firebase

The proprietary original. Included because if you are evaluating Appwrite alternatives and self-hosting is not actually a requirement, Firebase remains the most complete mobile-first backend, with client SDKs and offline behaviour nobody on this list matches.

You give up self-hosting entirely, accept a query model with real constraints, and take on pricing that is a function of document reads. If self-hosting was the whole point of Appwrite for you, skip this one.

6. Convex

A different shape worth knowing about: TypeScript functions with transactional guarantees and reactive queries, where subscribed clients update automatically when underlying data changes. If the part of Appwrite you lean on hardest is realtime, Convex's model is more advanced than subscription-to-changes.

Managed-first, with its own data store rather than a SQL database, so it trades away most of what makes Supabase a safe exit.

7. Unbundling: auth library, Postgres, your own server

This is PandaStack's position and it is a genuinely different answer, so I will describe it as such rather than as a drop-in. There is no bundled auth, no storage API and no realtime service here. The proposition is that the bundle stopped being worth it, and the pieces are now individually good enough to assemble.

The reason this is more viable than it was three years ago is that self-hosted auth libraries got genuinely good. Better Auth, Lucia and Auth.js turn the three-week auth project into an afternoon, in your own codebase, against your own database.

// Auth as a library in your app, sessions in your own Postgres.
import { betterAuth } from "better-auth";
import { Pool } from "pg";

export const auth = betterAuth({
  database: new Pool({ connectionString: process.env.DATABASE_URL }),
  emailAndPassword: { enabled: true },
});

// Storage stays in object storage; realtime is a WebSocket route in
// the same long-running server, which a microVM app can hold open.

PandaStack's part is running that server and that Postgres: git-driven deploys with no Dockerfile, managed Postgres 16 with branching and point-in-time recovery, and apps that scale to zero on one rate card — $0.054 per active vCPU-hour plus $0.0162 per working-set GiB-hour.

Deciding in five minutes

1. If the database abstraction is what hurts, go to Supabase. Everything else is secondary to getting back to plain SQL.
2. If operational weight is what hurts and your app fits on one machine, PocketBase will feel like relief.
3. If you only ever wanted auth, add an auth library to the app you already have and delete the platform.
4. If self-hosting was never the requirement and you inherited it as an assumption, check that first — it eliminates or reinstates half this list on its own.
5. Whatever you pick, export your users first and confirm you can reproduce password hashes and OAuth identities. That is the migration step that actually blocks people, and it is better to discover it on a Tuesday than on cutover night.