Appwrite vs Supabase

Last reviewed Aug 26, 2026 · 720 words

Both bill themselves as the Firebase you can self-host, and both mean it, but they got there from opposite ends. Supabase started with PostgreSQL and generated everything else from it: the REST API is PostgREST reading your schema, auth is a Postgres-backed service, realtime is a listener on the write-ahead log. Appwrite started with the API and put a database behind it: you define collections and attributes in a console, the platform stores them (in MariaDB, though you will never talk to MariaDB directly) and exposes them through SDKs. That is the whole choice in one line. If you think in tables and SQL, Supabase. If you think in SDK calls and would rather never see a database, Appwrite.

The database is the product in Supabase and an implementation detail in Appwrite

With Supabase, anything you can express in Postgres you get for free: joins, views, triggers, full-text search, extensions such as pgvector and PostGIS, and row-level security policies that double as your authorization layer. The Postgres-for-everything argument applies with full force, and it cuts both ways: you need to know Postgres, and RLS policies are the source of most "why can't my user read this row" tickets.

Appwrite gives you a document-style database with typed attributes, indexes, a relationships attribute type and per-document permissions set through the API rather than through SQL. The trade is depth for approachability: reporting queries that are one SQL statement in Supabase become several round-trips or a function in Appwrite. For a mobile app whose data is "users, their things and their files," that limit rarely bites. For anything analytical, it does.

Self-hosting: one installer against a dozen containers

Appwrite installs with a single docker run that generates a compose file and asks a handful of questions; behind it sit MariaDB, Redis, a Traefik ingress and a set of worker containers. The catalogue puts it at 2,048 MB and Medium, with a fair warning that enabling every service (function runtimes especially) makes it hungrier.

Supabase self-hosted is the same dozen-service stack the PocketBase vs Supabase piece describes: Postgres, GoTrue, PostgREST, Realtime, Storage, Kong, Studio, edge functions and more, driven by one compose file you must populate with matching JWT secrets before anything works. Hard and 4,096 MB in the catalogue, and both figures are right. Upgrades are where the gap shows most: Appwrite's migration is one documented command; a Supabase upgrade means checking each service's image tag against the compatibility notes. Supabase's self-hosted path also trails its hosted product in polish, while Appwrite has treated self-hosting as the primary way to run it since 2019.

SDKs, functions and the mobile question

Appwrite ships official SDKs for Web, Flutter, Apple, Android and React Native plus every major server language, and its functions run in a dozen runtimes, Node, Python, PHP, Dart, Go and Ruby among them. Supabase's strongest client is supabase-js; its Flutter and Swift SDKs are good but younger, and its edge functions run on Deno only. Both do OAuth with a long provider list, realtime subscriptions and file storage. Add Appwrite's built-in messaging (email, SMS and push through providers you configure) and the pattern is clear: Appwrite is broader, Supabase is deeper.

Decision table

What I'd do

If the project has a data model I would sketch as tables, I take Supabase and accept the operations bill, because the schema and the skills transfer to any Postgres for the rest of my career. If it is an app-shaped product, particularly mobile, with a small team that wants to ship rather than administer, I take Appwrite; it is the more finished self-hosted experience of the two. The dev-platforms category has lighter options if either feels like too much stack for a side project.