Appwrite, Firebase, and Supabase: The Backend Decision in 2026

The choice between proprietary and open source

I conclude that teams choosing between Firebase and open-source alternatives like Appwrite or Supabase face a fundamental split between proprietary convenience and self-hosted control. Firebase keeps your data on Google servers and scales costs based on usage patterns that can lead to $2,000 monthly bills for growing startups. Firebase provides NoSQL databases, including Cloud Firestore for document management and Realtime Database for JSON trees.

If you require a platform you can own, Appwrite provides a single Docker container for easy deployment. Supabase, conversely, requires managing multiple containers like Kong and PostgREST, which makes self-hosting a heavier task. Appwrite supports function runtimes across over 10 different languages, including Dart, Bun, Kotlin, and Swift. Firebase manages everything with no self-hosting support, whereas Appwrite messaging includes ten different providers to leverage major communications providers for SMS, email, and push notifications. If you need a platform that integrates tightly with mobile frameworks, Appwrite’s first-class Flutter SDK provides a more cohesive experience than the alternatives. You should pick Appwrite if your team prefers a document-style API or needs a mobile-first experience.

New requirements for Appwrite deployment

The recent changes to Appwrite’s self-hosted architecture introduce a new requirement for managing execution and usage data. You must now provision an external Clickhouse backend because function and site executions no longer pull from the project MariaDB database. This new dependency makes the installation less simple than the previous Docker Compose configurations. I think this additional complexity undermines the "one-line" installation advantage that makes Appwrite attractive for small teams. While Appwrite uses a document-based API to manage collections and documents, Supabase provides the full power of PostgreSQL with row-level security and joins. If you prioritize full data residency and want to avoid vendor lock-in while using a document-based model, Appwrite’s single Docker container remains the most straightforward and reliable path for your production deployment.

Appwrite’s database uses an abstraction layer on top of MariaDB, allowing developers to develop custom schema and use queries without any pre-existing SQL knowledge. The platform also includes a dedicated API for image transformations, such as manipulating resolution, reformatting, and compression. It uses WebSockets for real-time communication through an internal events system. Appwrite’s storage also includes file encryption and gzip or zstd compression for network transfer optimization. Functions in Appwrite execute in response to specific events like HTTP requests, database changes, or authentication events. Appwrite provides a collection of microservices, all orchestrated through Docker Compose.

Pricing and scaling costs

Pricing models for these platforms diverge significantly as you scale. Appwrite Cloud’s free tier includes 75,000 monthly active users and 10 GB of storage without ever pausing. In contrast, Supabase free tier projects pause after one week of inactivity and only provide 500 MB of database space.

I look at the differences in monthly active user (MAU) limits and storage. Appwrite Cloud’s Pro plan provides 200,000 MAUs, 150 GB of storage, 2 TB of bandwidth, and 3.5 million function executions. Supabase’s Pro plan provides 100,000 MAUs, 8 GB of database space, and 250 GB of bandwidth. Supabase provides S3-compatible storage and its real-time engine uses an Elixir server that listens to the PostgreSQL replication stream to broadcast changes over WebSockets. Is the complexity of the Supabase Elixir-based real-time engine worth the higher database power? You know the drill, so pick the tool that fits your schema. If you need the power of relational joins, pick Supabase, but if you need simplicity, choose Appwrite.