Which backend fits: Supabase Cloud or self-hosted Appwrite
Supabase Cloud fits Postgres-first teams that are content to hand day-to-day operations to a hosted operator, while self-hosted Appwrite fits teams that need several projects on one installation, a wider service set, or the data kept entirely on their own servers. The choice usually starts from one of three triggers: a renewal or price change on Supabase Cloud, a data residency rule, or concern about lock-in to a single hosted provider. Those triggers point toward different answers, so it helps to name which one applies before comparing features. Supabase Cloud suits a team whose app is built around SQL. Each Supabase project is a Postgres database, so row-level security policies, database functions, triggers and views carry over naturally, and PostgREST exposes the schema to client apps. Supabase Cloud also takes on the operating work: upgrades, managed backups and point-in-time recovery, and branching are provided as part of the hosted service. Self-hosted Appwrite fits a different profile. Its Console can manage several projects, its README lists Auth, Databases, Storage, Functions, Sites, Messaging, Firewall, Realtime and MCP, and it provisions PostgreSQL by default while still supporting MariaDB and MongoDB. Teams that want those services in one place, and that will run the stack themselves, can weigh that breadth directly.
The decision turns on three questions. First, where must the data live: a self-hosted Appwrite install runs in the infrastructure you choose, whereas a Supabase Cloud project sits in one chosen AWS region, so confirm which regions your residency rule allows. Second, who runs operations: self-hosting either product moves upgrades, backups, monitoring and on-call to your team, and Appwrite's own Helm chart documentation notes that its built-in datastores run a single replica without failover, so production planning must include managed or operator-run databases. Third, how much Postgres-specific logic the app uses: heavy reliance on SQL policies, triggers and extensions favors Supabase, while an app that mostly uses the Appwrite SDKs and its permission model may move more easily to Appwrite. Confirm these three answers in writing with your platform and security owners before you request a quote.
Which scenarios favor each option
This table maps common buyer situations to the option that usually fits better, with the reason tied to supplied facts about each platform. Read each row as a starting point, then confirm the points marked for verification against your own requirements and current release notes.
| Scenario | Better fit | Reason |
|---|---|---|
| Postgres-heavy app with SQL reporting and joins | Supabase Cloud or self-hosted Supabase | Supabase gives each project a Postgres database with PostgREST, while Appwrite 2.0 defaults to PostgreSQL but also supports MariaDB and MongoDB, so Supabase is the more direct Postgres model. |
| Several internal apps that need separate projects | Self-hosted Appwrite | Self-hosted Supabase runs as a single project per Studio, while Appwrite supports multiple projects, so confirm the isolation model you need for each app. |
| Strict data residency in your own data center | Self-hosted Appwrite or self-hosted Supabase | Both run in infrastructure you choose, so the decision depends on which stack your operators can support, not on hosted region selection (confirm with your residency team). |
| Small team without platform staff | Supabase Cloud or Appwrite Cloud | Self-hosting either stack means operating Docker or Kubernetes, backups and upgrades yourself, so a hosted plan may suit a team with no platform engineers. |
| Migrating from Firebase with existing user passwords | Self-hosted Appwrite | Appwrite's Users API accepts imported Firebase-style scrypt hashes along with bcrypt, Argon2 and others, which helps avoid forced password resets (confirm the exact hash parameters with a test import). |
| Needs functions and realtime in one self-hosted stack | Self-hosted Appwrite | Appwrite's README lists Functions, Realtime, Messaging and Sites in one platform, though its sample Compose file adds several services you must run and monitor. |
| Production data needing high availability | Neither without extra design | Appwrite's Helm chart docs say its built-in datastores run a single replica without failover, so plan managed or operator-run databases for either stack. |
| Need for newest features in a fast-moving release line | Confirm before choosing | Appwrite 2.0 changed the engine and ships DocumentsDB and VectorsDB disabled until PostgreSQL and MongoDB engines are deployed, so test upgrades in staging first. |
Where your data lives under each model
Supabase Cloud hosts each project in one main region chosen from 17 AWS regions, so residency is set when the project is created and is the first thing to verify against your obligations. The vendor operates the Postgres database, Auth, Storage and the hosted control plane, which means the data processing agreement, sub-processors and security reports come from Supabase rather than from your team.
- Fixed region: Confirm the chosen region in the project settings and check whether it meets your residency rules before loading personal data.
- Vendor-run operations: Patching, backups and access to the underlying infrastructure sit with the provider under its shared responsibility terms.
- Shared responsibility: Row-level security policies, key handling in your apps and user data retention remain your responsibility.
- Compliance evidence: Ask Supabase which current reports and contractual terms cover the plan you intend to buy, and which add-ons are required for regulated data.
- Support boundary: Plan-level support and SLAs come from the vendor, so incident timelines depend on your contract.
Before relying on this model, confirm the region, the sub-processor list and the contractual terms in writing with the vendor.
Self-hosted Supabase is the Apache-2.0 stack deployed with Docker Compose in infrastructure you choose, such as your own data center, a sovereign cloud or a private cloud account. Data stays wherever you place the Postgres volume, Storage backend and logs, so residency is decided by your hosting choice. The compliance burden moves to your team, because you own the operating controls that the hosted plans would otherwise supply.
- Placement control: Choose the physical or cloud location of the database, object storage and backups, and document it in your data inventory.
- Secrets and access: The guide warns against starting with the placeholder values in
.env.example, so generate secrets and restrict Studio access before exposing it. - Community support: Supabase describes self-hosting as community-supported, so vulnerability response and upgrade questions need an internal owner or a support partner.
- Logging and backups: Managed backups and point-in-time recovery are not available when self-hosting, so you must design and test those controls yourself.
- Upgrade risk: Each Docker configuration release pins specific upstream service versions, and some Storage migrations are one-way, so take a database backup before updating.
Confirm the hosting location, the key custody model and who receives security notices before treating this as a compliant environment.
Appwrite Cloud is the hosted edition of the BSD-3-Clause Appwrite platform, sold in Free, Pro and Enterprise plans. The vendor runs the platform and the projects you create on it, so the residency, backup and security questions are answered by the Appwrite contract and product documentation. A Free project that reaches a resource limit freezes in read-only mode, which is an operational constraint your data plan must account for.
- Hosted operations: Appwrite operates the infrastructure, and your team manages projects, keys and user access through the Console and APIs.
- Plan limits: The Free plan pauses projects after a period of inactivity and freezes them at limits, while Pro projects keep running with overage charges and optional budget caps.
- Backups: Pro includes daily backups, but you should confirm restore scope, retention and whether they meet your recovery objectives.
- Region and sub-processors: Ask the vendor which regions host your project and which sub-processors touch user data.
- Enterprise terms: Custom contracts are the route for specific audit rights, data processing terms and support commitments.
Ask for the hosting region, backup retention and contractual compliance documents before you put regulated data into a hosted project.
Self-hosted Appwrite runs under the BSD-3-Clause license with Docker or the official Helm chart in your own cloud account, data center or air-gapped network. Residency, encryption keys and identity stores are under your control, but so are availability and recovery. The published Helm documentation states that the built-in PostgreSQL, Redis, ClickHouse and object storage each run a single replica without replication or failover, so production deployments usually replace those components with managed services or operators.
- Full data control: Placement of PostgreSQL, ClickHouse, object storage and backups is a design decision you document and audit.
- Identity ownership: User records and password hashes stay in your database, and the Users API accepts several hash formats for migration from other platforms.
- Availability design: Plan replication, failover and backup testing for each stateful component rather than relying on the default single-replica setup.
- Compliance preparation: DeployOpen can prepare configuration baselines, access controls and evidence collection, while independent auditors issue any attestation or certification.
- Dependency on upgrades: Appwrite 2.0 replaced the engine underneath, and existing 1.9.x installs require a migration, so schedule that work within your change process.
Before production use, confirm the datastore topology, backup and restore tests, and which auditor or certification body will assess your environment.
Multi-project support and the data model gap
The first question for a team with several apps is how many isolated projects one installation can hold. Self-hosted Supabase runs as a single project, and its Studio does not support multiple organizations or projects. If you run a separate Supabase stack per application, each one carries its own Postgres instance, containers, secrets, upgrade cycle and backup job. Appwrite's self-hosted install takes a different approach: its Console lets you create multiple projects on one installation, so teams that want tenant or application separation inside a single deployment can keep it there. Confirm in a test environment how project isolation, API keys and quotas behave in the Appwrite release you plan to run, because the answer determines how many stacks you operate.
The second gap is the database itself. Supabase gives each project a Postgres database, so schema, row-level security policies, functions, triggers and extensions are all Postgres objects that PostgREST exposes directly. Appwrite 2.0 provisions PostgreSQL by default, with MariaDB and MongoDB also supported, but its databases are reached through Appwrite's own API and permission model rather than through PostgREST. That means Postgres-specific logic in your Supabase project (policies that call auth.uid(), SQL functions exposed as RPC endpoints, and views built on Postgres features) will need to move into Appwrite permissions, Functions or application code. Inventory those objects before you commit. Each one is a rewrite task with its own testing, and the cost of that work usually exceeds the cost of moving rows and files.
Plan the migration around that inventory. Export your schema and list every policy, function and trigger, then mark which ones Appwrite can express natively and which need a function running on the Open Runtimes executor. Ask Appwrite how a dataset maps across its database engine choice, and ask your DeployOpen or internal team to run a rewrite of one representative table end to end before scheduling the rest. Keep a record of which features you could not reproduce, so that product owners sign off on the change in behavior rather than discovering it in production.
What running each platform asks of your team
Both self-hosted stacks replace Supabase Cloud's managed operations with work your team owns. The cards below cover the resource baseline, datastore resilience, upgrade cadence, support model and secret handling that shape that work on each platform.
Resource baseline for each stack
Appwrite's installation guide asks for 2 CPU cores, 4 GB of RAM and 2 GB of swap, with Docker Compose version 2, and its sample Compose file starts PostgreSQL, Redis, Traefik, ClickHouse, the API, workers, realtime, the console and an Open Runtimes executor. Supabase's Docker guide gives a minimum of 4 GB RAM, 2 cores and a 40 GB SSD. Compare the full service count, not only the headline minimums, and confirm the disk growth you expect for ClickHouse and Storage.
Single-replica datastores on Appwrite
Appwrite's Helm chart docs state that the built-in PostgreSQL, Redis, ClickHouse and object storage each run a single replica with no replication or failover. Production installs therefore need managed services or database operators for those tiers. Supabase Cloud handles this inside the platform, so you will budget for replication, backups and restore testing that you do not own today.
Upgrades that change the engine
Appwrite 2.0, released on September 4, 2026, replaced the engine underneath and rebuilt the Console, and existing 1.9.x installs need a one-command upgrade plus a migration. Appwrite 2.5.0 followed on October 13, 2026. Plan a staging rehearsal and a database backup before each minor move. Self-hosted Supabase 0.8.3 pins specific Auth, PostgREST and Realtime versions, so each Docker configuration release is a set of upstream changes you pull and recreate yourself.
Community support on Supabase
Supabase's self-hosting docs state that self-hosted Supabase is community-supported through GitHub Discussions, GitHub Issues, Discord and Reddit, and that enterprises should contact the Growth Team. Appwrite's self-hosted edition is open source, but confirm with Appwrite what support tier you can buy for your installation before you commit. Write down who answers a production incident on each option, and at what hours.
Secret hardening before first start
Supabase's Docker guide warns never to start with the placeholder secrets in .env.example, and provides scripts that generate secrets and the JWT key pair. Protect Studio with the HTTP basic auth set through DASHBOARD_PASSWORD. Appwrite also requires you to set its keys during the setup wizard on port 20080. Assign an owner for key rotation, and confirm how each platform's JWT or API keys are rotated without downtime.
Backups you schedule and test
Supabase Cloud's daily backups and point-in-time recovery do not carry over to self-hosting, and Appwrite Cloud's daily backups are a hosted feature too. On either self-hosted stack, your team defines backup schedules for Postgres and file storage, keeps copies off the host, and runs restore drills. Ask for the restore time you would commit to and test it against a copy of production.
What a move from Supabase Cloud to Appwrite involves
The sequence turns a Supabase Cloud project into a working Appwrite installation that you run, with users, data, files, functions and client traffic moved in a checked order. Each step closes with a verifiable output, so the cutover happens only after the target has been proven.
Inventory users, data, storage and functions
Your team, with DeployOpen if you engage us, lists every table and schema in the Supabase Cloud project, every auth user and provider configuration, every Storage bucket and its access rules, and every Edge Function. Record which Postgres-specific pieces exist, such as row level security policies, triggers, database functions, extensions and views, because these need separate handling. The output is a written inventory that marks each item as moved, rebuilt or retired.
Stand up the target Appwrite installation
Install the self-hosted Appwrite stack in your own infrastructure, following the installation guide for the release you select, and confirm it meets the documented minimum of 2 CPU cores, 4 GB of RAM, 2 GB of swap and Docker Compose version 2. If you plan to use the Helm chart for production, confirm in Appwrite's docs which datastores need managed services or operators, since the built-in datastores run a single replica without failover. The output is a reachable Console, a working API endpoint and a backup target configured before any data arrives.
Check hash compatibility before importing users
Export the auth users from Supabase Cloud and confirm that their password hashes can be imported into Appwrite's Users API without a forced reset. Appwrite accepts several hash algorithms, but the hashes and their parameters must match one of them, so verify this with a small test set first. Users whose hashes do not match need a password reset path or an alternative sign-in method, which you should plan with your security team. The output is a documented list of which hash types and users import cleanly.
Import users and data through Appwrite Migrations
Run Appwrite Migrations against the Supabase Cloud project to import users, databases and files into the target project, then review the migration report line by line. Treat the import as partial for relational data: confirm in Appwrite's migration documentation and in a test run which rows, constraints and column types arrive intact and which need manual reconstruction. Functions are not moved by the migration, so they are handled in a later step. The output is a test-environment dataset with reconciled row counts per table and a list of gaps.
Move files and rewrite Postgres-specific logic
Copy Storage objects into Appwrite Storage, then verify file counts, sizes and checksums against the inventory and reapply bucket permissions in Appwrite's model. Rewrite the Postgres-specific logic identified in the first step, including row level security rules, triggers and database functions, as Appwrite permissions, collections and Functions running on the Open Runtimes executor. Have an engineer who knows both models review each rewrite, since behavior can differ. The output is a file reconciliation report and a signed-off list of rewritten rules with test cases that pass against the target.
Update clients, SDKs and domains for cutover
Replace the Supabase client libraries in your web, mobile and server code with the Appwrite SDKs for your platforms, point the new endpoints at your self-hosted domain, and update redirect URLs, email templates and OAuth callbacks. Run the front-end and back-end test suites against the target in a staging environment. Schedule the cutover window with your product owners and freeze writes to the Supabase Cloud project during the final data sync. The output is a staging sign-off and a documented rollback path to the Supabase project.
Run a tested restore and cut over production
Perform the final data and file sync, switch the domains and client configuration to the Appwrite installation, and monitor authentication, database reads and writes, uploads and functions as they run in production. Before you decommission Supabase Cloud, restore the Appwrite backups into a separate environment and confirm that the restored data matches production. Keep the Supabase Cloud project until the restore test passes and your retention obligations are met. The output is a restore report and a decommissioning record for the old project.
Cost components on each side
Moving from Supabase Cloud to self-hosted Appwrite changes who you pay and for what. The hosted subscriptions are one recurring line, while the self-hosted side splits into servers, backup tooling, upgrades and the people who keep the platform running. Compare these components line by line before setting a budget.
Supabase Cloud and Appwrite Cloud subscriptions
Both vendors sell hosted plans with a Pro tier from $25 per month, according to their pricing pages, and each plan carries limits on bandwidth, storage and monthly active users. Confirm which plan and overage terms apply to your project, because the cost of staying hosted rises with usage and the subscription is recurring. A self-hosted move removes this line but adds the components below, so compare the full set, not the plan headline.
Servers, storage and network
Self-hosted Appwrite is paid for through your own infrastructure: compute, disk, object storage and egress from your cloud account or data center. The Appwrite installation guide lists 2 CPU cores, 4 GB of RAM and 2 GB of swap as a starting point, and production sizing grows with users, files and functions. This is recurring, and it rises with data volume, traffic and the number of environments you keep running.
Replicas and high availability
The Appwrite Helm chart runs its built-in PostgreSQL, Redis, ClickHouse and object storage with a single replica and no failover, so production data usually moves to managed services or operators. Those services are a recurring cost with their own pricing, and they replace the hosted redundancy you currently pay for inside the Supabase or Appwrite Cloud subscription. Ask your platform team what availability target they need before choosing this split.
Backup tooling and restore testing
Hosted plans include daily backups on Appwrite Pro, while self-hosted backups are your responsibility. Budget a one-time set-up for backup jobs, off-site storage and a restore runbook, then a recurring cost for storage and for periodic restore tests. Tooling is often open source, but the time to prove that restores work is the expensive part, and it grows with data size.
Upgrades and on-call time
Appwrite 2.0 changed the engine underneath and existing 1.9.x installs upgrade with one command and a migration, and releases continue, including 2.5.0 on October 13, 2026. Each upgrade, patch and security fix consumes engineering time, and someone must answer incidents outside business hours. Ask who owns each task, what a support agreement covers, and whether the team has capacity for these recurring duties.
Questions buyers ask before choosing Appwrite or Supabase
How much effort does running self-hosted Appwrite take compared with Supabase Cloud?
Self-hosted Appwrite is more operating work than a hosted plan, and the effort depends on how many services you run and how you run the datastores. The sample Docker Compose file runs PostgreSQL, Redis, Traefik, ClickHouse, the API, workers, realtime, the console and an Open Runtimes executor, so you patch, monitor and back up each of them. The installation guide lists 2 CPU cores, 4 GB of RAM and 2 GB of swap as the starting requirements. Ask your team to estimate the recurring work for upgrades, backups and on-call, because that recurring cost, not the first install, usually decides the comparison.
How long does a migration from Supabase Cloud to Appwrite take?
The duration depends on the data volume, the number of tables and functions you rewrite, the file storage size and how much Postgres-specific logic your app uses. Appwrite Migrations can import users, databases and files from Supabase, but rows move partially and functions do not move at all, so the rewrite work often sets the timeline. Get a written plan from your provider that lists each data type, its import path and the testing window before you commit to a date.
Can our in-house team migrate and run Appwrite without outside help?
A capable platform team can do it alone if it has time, Docker and Kubernetes experience, and someone who owns backups and incident response. The harder parts are the datastores: the Helm chart documentation says the built-in PostgreSQL, Redis, ClickHouse and object storage each run a single replica without replication or failover, so production use needs managed services or operators. Ask whether your team can cover those responsibilities for the full year, not just the cutover.
What does our team need to provide for a self-hosted Appwrite project?
You need infrastructure you control, people who own the platform after launch, and access to your current Supabase or Firebase projects for export. Plan for a DNS and TLS setup, secret management for the generated keys, a backup target and a monitoring stack. You also need application owners who can review rewritten security rules and functions. Confirm these inputs in writing before the scope is agreed, since each one changes the work.
Is Appwrite Cloud a safer middle path before we self-host?
Appwrite Cloud can be a useful stepping stone because it runs the same BSD-3-Clause stack without the operating work of your own servers. It is not the same as self-hosting, though, since you depend on the hosted provider's plans, limits and operating choices. The pricing page lists a Free plan that pauses after 1 week of inactivity and a Pro plan from $25 per month, and it describes read-only freezes on Free projects that hit limits. Check those terms against your data residency and continuity needs before you rely on it as an interim step.
How does moving password hashes avoid forcing users to reset passwords?
Password hashes move without resets when the target platform accepts the same hashing algorithm and parameters. Firebase Auth uses a modified scrypt by default, and the Firebase CLI exports hashes with their parameters. Appwrite's Users API accepts imported Scrypt modified hashes along with bcrypt, Argon2, MD5, PHPass, Scrypt and SHA hashes. Ask your provider to confirm which hash type your current users have and to run a test import with real export data before cutover.
What does a DeployOpen fixed-scope engagement cover for Appwrite?
A DeployOpen engagement is fixed in scope, with deliverables and timelines agreed in writing before work starts. Depending on what you choose, the work can include planning, implementing and hardening the self-hosted Appwrite stack in your own cloud account, data center or air-gapped network, plus migration, backups, documentation and upgrade planning. Security testing and cyber ranges are separate services in the same scope. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications. Ongoing support and upgrades are available as retainers, and the quote follows from the written scope.
How DeployOpen helps you evaluate and run either platform
DeployOpen is a Chainscore Labs company that plans, implements, customizes, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a team choosing between Supabase Cloud and self-hosted Appwrite, that work can start before any decision is made: a proof of concept that runs your real authentication flows, a check of how the Appwrite Console and the Appwrite Database API behave with your data model, and a written view of which features you would need to rebuild. Most engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before work begins, and a quote follows from that written scope. DeployOpen does not publish a price list.
Once you choose a platform, the work that matters is the operating model: a pinned Docker or Helm release, secrets generated per environment, backups you have tested by restoring them, and an upgrade path for the 2.x line, including the one-command migration from 1.9.x installs described in the Appwrite 2.0 release notes. DeployOpen can build that runbook, set up the built-in datastores or move them to services you already operate, and document the evidence a compliance assessor will ask for. It can also provide security testing of the applications and APIs built on the backend. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Those come from independent auditors and certification bodies.
Ongoing support, upgrades and continuous testing are available as retainers, which suit teams that will carry the platform after launch. DeployOpen is not an official partner, reseller or certified provider of Appwrite, Supabase or any other vendor, so ask any provider you speak with to show their scope in writing, including who answers for security patches and what happens when a release breaks a client integration. Before you request a quote, confirm the facts that drive the work: your required regions, whether you need multiple projects in one environment, your user count and the hashing algorithm of your current password store.
