---
title: "Nhost vs Appwrite vs Supabase: Self-Hosted BaaS Compared 2026"
author: "Nate Laquis"
author_role: "Founder & CEO"
date: "2026-05-03"
category: "Technology"
tags:
  - Nhost vs Appwrite
  - self-hosted BaaS
  - Supabase self-hosted
  - backend as a service
  - BaaS comparison 2026
excerpt: "Running your own backend as a service gives you full control over data, costs, and infrastructure. This guide compares Nhost, Appwrite, and Supabase across every dimension that matters when you self-host."
reading_time: "14 min read"
canonical_url: "https://kanopylabs.com/blog/nhost-vs-appwrite-vs-supabase-self-hosted-baas"
---

# Nhost vs Appwrite vs Supabase: Self-Hosted BaaS Compared 2026

## Why Self-Hosted BaaS Deserves Your Attention in 2026

Managed BaaS platforms are convenient until they are not. Pricing spikes after a traffic surge, a vendor deprecates an API your product depends on, or a compliance audit reveals your user data is stored in a region you cannot control. Self-hosting solves all three problems by putting the entire backend stack on infrastructure you own.

Three open-source platforms have emerged as the serious contenders for self-hosted BaaS: **Nhost**, **Appwrite**, and **Supabase**. Each one ships a database, authentication, file storage, serverless functions, and a dashboard you can run on your own servers. But they make fundamentally different architectural decisions, and those decisions ripple through every layer of your application.

![Data center with rows of illuminated servers and network cabling](https://images.unsplash.com/photo-1558494949-ef010cbdcc31?w=800&q=80)

At Kanopy, we have deployed all three platforms for clients with strict data-residency requirements, tight infrastructure budgets, or simply a preference for owning their stack. This comparison is built from that hands-on experience. We will cover databases, auth, real-time, storage, functions, deployment, pricing, and migration paths so you can pick the right foundation before your team writes a single line of backend code.

One clarification before we dive in: all three platforms offer managed cloud tiers. This guide focuses specifically on the self-hosted experience, where you run the stack on your own VPS, bare-metal server, or Kubernetes cluster. The managed versions share core functionality with their self-hosted counterparts, but operational details differ significantly.

## Database Engines: PostgreSQL, Hasura, and MariaDB

The database is the most consequential choice in any BaaS stack because it determines your query language, your data model, your tooling ecosystem, and your migration options if you ever outgrow the platform.

### Supabase: Raw PostgreSQL with PostgREST

Supabase gives you a plain PostgreSQL instance. No wrappers, no compatibility layers. You get every extension the engine supports: pgvector for embeddings, PostGIS for geospatial queries, pg_cron for scheduled jobs, and hundreds more. The API layer is **PostgREST**, which auto-generates a RESTful API from your database schema. Every table, view, and function becomes an endpoint. Row-Level Security policies control access at the database level, and the client library translates JavaScript method chains into PostgREST queries.

The self-hosted Supabase stack bundles PostgreSQL 15+, PostgREST, GoTrue (auth), Realtime, Storage API, Kong (API gateway), and a Studio dashboard. You can connect any PostgreSQL client, ORM, or analytics tool directly to the database. Your data is never locked behind a proprietary protocol.

### Nhost: PostgreSQL with Hasura GraphQL

Nhost also runs PostgreSQL, but instead of PostgREST it places **Hasura** in front of the database. Hasura introspects your schema and generates a full GraphQL API with queries, mutations, subscriptions, and relay-style pagination. If your frontend team already uses Apollo Client, urql, or Relay, Nhost feels natural. You write GraphQL queries, Hasura compiles them into optimized SQL, and PostgreSQL executes them.

Hasura also provides a permissions system that maps roles to table-level and row-level access rules. These permissions are configured through the Hasura Console or metadata files, not raw SQL policies like Supabase's RLS. For teams that prefer a GUI-driven approach to authorization, this is an advantage. For teams that want their access logic version-controlled as SQL migrations, it adds a layer of indirection.

One thing worth calling out: Nhost's Hasura dependency means you are coupling your API layer to Hasura's release cycle and licensing decisions. Hasura moved parts of its feature set to a paid "Cloud" or "Enterprise" tier over the years. The open-source Community Edition remains capable, but advanced features like remote schema stitching with caching or read replicas may require a Hasura license on top of your Nhost deployment.

### Appwrite: MariaDB Under the Hood

Appwrite takes a completely different path. Its database layer runs on **MariaDB** (a MySQL fork), and it exposes a document-style API on top of it. You create "collections" and "documents" through Appwrite's SDK or REST API, and Appwrite translates those operations into MariaDB queries internally. You do not write SQL. You do not get direct database access by default.

This design decision has tradeoffs. On the positive side, the API is simple and consistent across every Appwrite SDK (Flutter, Swift, Kotlin, Python, Node, and more). On the negative side, you lose the ability to write complex joins, window functions, CTEs, or any query that does not map to Appwrite's document model. If your data is relational, you will find yourself duplicating fields across collections or making multiple API calls to assemble related records.

**Our take:** If your team values SQL access, extensions, and direct database connectivity, Supabase or Nhost are the clear choices. If your team prefers a simplified document API and does not need complex queries, Appwrite's abstraction keeps things approachable. For projects that require GraphQL as a first-class citizen, Nhost with Hasura is the strongest option.

## Authentication Systems Compared

Authentication is the feature that saves the most development time in any BaaS platform. Building email/password flows, OAuth provider integration, token refresh logic, and MFA from scratch takes weeks. All three platforms handle this, but their implementations differ in meaningful ways. For deeper background on rolling your own auth layer, see our [authentication guide](/blog/how-to-build-secure-authentication).

### Supabase Auth (GoTrue)

Supabase uses **GoTrue**, an open-source auth server written in Go. It supports email/password, magic links, phone OTP, and over 30 OAuth providers including Google, GitHub, Apple, Microsoft, Discord, and Slack. Sessions are JWT-based. The killer feature is deep integration with PostgreSQL Row-Level Security: your RLS policies can call `auth.uid()` to reference the currently authenticated user, and the database enforces access rules without any application middleware.

Self-hosted GoTrue is battle-tested. It handles token refresh, password resets, email confirmations, and invite flows out of the box. SAML and SSO support are available in newer versions, which matters for B2B applications where enterprise customers require identity federation.

### Nhost Auth (Hasura Auth)

Nhost ships its own auth service called **Hasura Auth** (formerly nhost-auth). It supports email/password, magic links, OAuth providers, anonymous sign-in, and WebAuthn/passkeys. JWTs issued by Hasura Auth include custom claims that map to Hasura roles, so your GraphQL permission rules can reference the user's role and ID directly.

Anonymous authentication is a standout feature. A user can start using your app without creating an account, and you can later link that anonymous session to a real account. This pattern is powerful for e-commerce, onboarding flows, and any product where you want to reduce friction before asking for credentials.

### Appwrite Auth

Appwrite's auth module supports email/password, phone OTP, magic links, OAuth providers, anonymous sessions, and team-based access. The team feature is Appwrite's differentiator: you can create teams, invite members, and assign roles, and the permissions system respects those team memberships natively. For multi-tenant SaaS applications, this saves significant custom development.

Appwrite also supports MFA with TOTP (authenticator apps) and recovery codes. The auth APIs are consistent across every Appwrite SDK, which means Flutter, React Native, Swift, and Kotlin developers all get the same auth experience.

![Server room with blue-lit rack-mounted hardware and networking equipment](https://images.unsplash.com/photo-1504868584819-f8e8b4b6d7e3?w=800&q=80)

**Our take:** Supabase wins on database-level auth integration. Nhost wins on GraphQL-native permissions and passkey support. Appwrite wins on built-in team management and multi-tenant auth patterns. All three are production-ready for most applications. The deciding factor is usually which permission model aligns with your application architecture.

## Real-Time Subscriptions, Storage, and Edge Functions

Beyond the database and auth, the remaining pillars of a BaaS stack are real-time data sync, file storage, and serverless compute. For a broader comparison of real-time backend options, check our [real-time BaaS comparison](/blog/convex-vs-supabase-vs-firebase-real-time-baas).

### Real-Time Capabilities

**Supabase Realtime** uses PostgreSQL's Write-Ahead Log (WAL) to detect changes and broadcasts them over WebSockets. You subscribe to INSERT, UPDATE, or DELETE events on specific tables, optionally filtered by column values. Supabase also supports Broadcast (arbitrary message passing between clients) and Presence (tracking online users in a channel). The architecture is straightforward, but it depends on PostgreSQL replication slots, which consume resources on your database server. On a self-hosted instance with limited RAM, heavy real-time usage can put pressure on the database.

**Nhost** inherits real-time from Hasura's GraphQL Subscriptions. You write a subscription query, and Hasura polls the database at a configurable interval (default one second) and pushes diffs to connected clients over WebSockets. This is not true event-driven streaming like Supabase's WAL-based approach. For most applications the polling interval is acceptable, but if you need sub-100ms latency on data changes, Hasura's polling model adds a floor to your response time.

**Appwrite Realtime** provides WebSocket-based subscriptions scoped to databases, collections, documents, files, and auth events. You subscribe to a "channel" like `databases.mydb.collections.messages.documents` and receive events when documents in that collection change. The system is event-driven and does not rely on polling. It works well for chat, notifications, and live dashboards.

### File Storage

All three platforms include object storage for user uploads, images, and documents. **Supabase Storage** stores files in an S3-compatible backend and generates signed URLs, supports image transformations (resize, crop, format conversion), and integrates with RLS for access control. **Nhost Storage** uses an S3-compatible layer (MinIO by default on self-hosted) with built-in image processing via a transformation API. **Appwrite Storage** supports local disk or S3-compatible backends, offers previews and image manipulation (crop, resize, rotate, watermark), and ties file permissions to Appwrite's role-based access model.

For self-hosted deployments, Supabase and Nhost default to MinIO or local S3-compatible storage. Appwrite can use the local filesystem out of the box, which simplifies single-server setups but requires manual configuration for redundancy.

### Serverless / Edge Functions

**Supabase Edge Functions** run on Deno. They execute TypeScript natively, support npm packages via import maps, and can call your PostgreSQL database directly. On self-hosted instances, you deploy Edge Functions through the Supabase CLI, and they run as Deno processes alongside the rest of the stack.

**Nhost Functions** are Node.js-based serverless functions deployed alongside your Nhost stack. They have access to the Hasura GraphQL endpoint and can execute admin-level queries. The function runtime is simpler than Supabase's Deno-based approach but more familiar to teams already working in the Node ecosystem.

**Appwrite Functions** are the most flexible in terms of language support. They support Node.js, Python, Ruby, PHP, Dart, Swift, Kotlin, Java, C++, and .NET runtimes. Each function runs in a Docker container, which provides strong isolation but introduces longer cold starts compared to Deno or lightweight Node runtimes. For polyglot teams or projects that need non-JavaScript function logic, Appwrite's runtime diversity is a significant advantage.

**Our take:** Supabase offers the fastest function execution with Deno. Appwrite offers the widest language support. Nhost keeps things simple with Node.js and tight Hasura integration. On the real-time front, Supabase's WAL-based streaming is the most responsive, Appwrite's event-driven model is solid, and Nhost's polling-based subscriptions are adequate for most use cases but not ideal for latency-sensitive features.

## Self-Hosted Deployment: Docker Compose, Kubernetes, and Operations

The operational burden of self-hosting is the factor that separates teams who thrive with this approach from teams who regret it six months later. Each platform has a different deployment footprint, and that footprint determines your infrastructure costs, maintenance workload, and scaling ceiling.

### Supabase Self-Hosted

Supabase provides an official `docker-compose.yml` that spins up PostgreSQL, PostgREST, GoTrue, Realtime, Storage, Kong, Studio (dashboard), and a meta service. The full stack runs about 10-12 containers. On a 4GB RAM VPS, the stack runs but leaves little headroom. We recommend at least 8GB for production workloads with moderate traffic.

Supabase does not ship an official Kubernetes Helm chart, though community-maintained charts exist. If you are running on K8s, expect to adapt the Docker Compose configuration yourself or use a community chart and validate it thoroughly. Database backups, SSL termination, and log aggregation are your responsibility. Supabase Studio gives you a web-based admin interface for managing tables, policies, and auth settings, which reduces the need for direct CLI access during day-to-day operations.

### Nhost Self-Hosted

Nhost provides a Docker Compose setup that includes PostgreSQL, Hasura, Hasura Auth, Hasura Storage, a functions runtime, and a dashboard. The stack is somewhat lighter than Supabase's because Hasura replaces several individual services (API gateway, real-time server) with a single binary. Expect 6-8 containers total. A 4GB RAM server handles light workloads, but Hasura's query compilation can be memory-intensive under load, so 8GB or more is still the practical minimum for production.

Nhost also offers a CLI (`nhost`) for local development that mirrors the self-hosted stack. This is useful for parity between dev and production. Kubernetes deployment is possible but, like Supabase, relies on community efforts rather than official Helm charts.

### Appwrite Self-Hosted

Appwrite has invested the most in making self-hosting accessible. A single `docker run` command pulls and starts the entire stack. Behind that command, Appwrite spins up MariaDB, Redis, a mail server, ClamAV (antivirus for file uploads), a Traefik reverse proxy, worker containers, and the main API server. The total container count is higher (15-20 depending on configuration), but the one-command setup hides that complexity.

Appwrite also provides an official installation script that handles SSL certificate generation with Let's Encrypt, domain configuration, and environment variable setup. For teams without deep DevOps expertise, this dramatically lowers the barrier to running a production-grade backend on a single VPS.

The tradeoff is resource consumption. ClamAV alone requires 1-2GB of RAM. The full Appwrite stack comfortably needs 8GB, and 16GB is recommended for production. Kubernetes support exists through community Helm charts, but Appwrite's architecture (heavy use of Docker-in-Docker for function execution) can create friction in K8s environments that restrict privileged containers.

![Analytics dashboard displaying system metrics and performance monitoring charts](https://images.unsplash.com/photo-1551288049-bebda4e38f71?w=800&q=80)

**Our take:** Appwrite has the smoothest initial setup experience. Supabase has the most mature ecosystem of third-party tooling and extensions around its PostgreSQL core. Nhost sits in the middle with a leaner container footprint but tighter coupling to Hasura's release cycle. All three require ongoing maintenance for backups, updates, monitoring, and security patches. If your team does not have someone comfortable managing Docker containers and database backups, the managed cloud versions are worth the premium.

## GraphQL vs REST, Pricing, and Migration Paths

API style, cost structure, and exit strategy are three factors that often get overlooked during initial platform evaluation. They matter enormously once your application is in production.

### GraphQL vs REST

**Nhost** is GraphQL-first. Every database operation goes through Hasura's GraphQL engine. You get auto-generated queries, mutations, and subscriptions. If your frontend uses a GraphQL client, the developer experience is excellent: type-safe queries, automatic cache updates, and fine-grained data fetching that eliminates over-fetching and under-fetching.

**Supabase** is REST-first through PostgREST, but its client library (`supabase-js`) provides a fluent query builder that feels like an ORM. You can also use the `pg_graphql` extension to expose a GraphQL endpoint, though it is less mature than Hasura's implementation. For teams that want GraphQL on Supabase, the path exists but requires additional configuration.

**Appwrite** is REST-first with a well-documented API and SDKs for 12+ languages. There is no built-in GraphQL support. If your project requires GraphQL, you would need to add a separate GraphQL layer (like Hasura or Apollo Server) on top of Appwrite, which defeats part of the all-in-one BaaS value proposition.

### Cost of Self-Hosting

Self-hosting eliminates per-request and per-user fees from the managed platforms. Your costs reduce to infrastructure and engineering time. Here is a rough breakdown for a production deployment serving 10,000 monthly active users:

- **Supabase self-hosted:** A $48/month VPS (8GB RAM, 4 vCPUs, 160GB SSD) handles this workload comfortably. Add $5-10/month for S3-compatible object storage and $5/month for automated database backups. Total: roughly $60/month. The managed Supabase Pro plan costs $25/month but adds usage-based charges for bandwidth, storage, and edge function invocations that can push bills to $100-200/month at this scale.

- **Nhost self-hosted:** Similar infrastructure requirements to Supabase. Budget $50-65/month for a comparable VPS plus storage. Nhost's managed Pro tier starts at $25/month with usage charges. Factor in Hasura's licensing if you need enterprise features.

- **Appwrite self-hosted:** The higher RAM requirements (ClamAV, more containers) push you toward a $72-96/month VPS with 16GB RAM for comfortable production operation. Total with storage: $80-110/month. Appwrite's managed Pro plan costs $15/month plus usage, which can be cheaper at lower scale but grows with bandwidth and function executions.

The crossover point where self-hosting becomes cheaper depends on your usage patterns. For read-heavy applications with moderate traffic, self-hosting saves money starting around 5,000 MAU. For write-heavy applications with lots of real-time connections, the savings start earlier because managed platforms charge premiums for database operations and concurrent connections.

### Migration Paths and Lock-In

If you ever outgrow your chosen BaaS or want to move to a custom backend, how painful is the migration?

**Supabase** has the easiest exit. Your data lives in PostgreSQL. Export it with `pg_dump`, point your application at a new PostgreSQL server, and swap the PostgREST API for your own backend. Your RLS policies, functions, and triggers are standard SQL that works on any PostgreSQL instance.

**Nhost** is almost as portable. The database is PostgreSQL, so `pg_dump` works. The Hasura layer adds metadata (permissions, relationships, event triggers) that lives outside the database. You would need to reimplement that logic in your own API layer during migration. If you are moving to a different GraphQL server like Apollo, the schema translation is manageable but not automatic.

**Appwrite** has the hardest exit path. Your data is in MariaDB, accessed through Appwrite's proprietary document API. There is no standard SQL interface exposed by default. Migrating means exporting collections through Appwrite's API, transforming the document structure into your target database's schema, and rewriting every data access call in your application. The more collections and relationships you have, the more work this requires.

**Our take:** If vendor portability matters to your team, PostgreSQL-based platforms (Supabase and Nhost) give you dramatically better exit options than Appwrite's MariaDB-backed document model. If you plan to stay on the platform long-term and value ecosystem breadth over portability, Appwrite's multi-language SDK support and simpler API surface may outweigh the lock-in concern.

## Community, Ecosystem, and Which Platform Fits Your Project

The right BaaS depends on your team's skills, your application's requirements, and how much operational complexity you are willing to accept. Here is how we think about the decision at Kanopy after deploying all three platforms across client projects. For additional context on how these platforms compare to proprietary alternatives, see our [Supabase vs Firebase comparison](/blog/supabase-vs-firebase).

### Community and Ecosystem

**Supabase** has the largest community of the three. Over 75,000 GitHub stars, an active Discord with tens of thousands of members, and a growing ecosystem of extensions, tutorials, and third-party integrations. The PostgreSQL foundation means you also inherit the entire PostgreSQL ecosystem: ORMs like Prisma and Drizzle, migration tools, monitoring solutions, and decades of community knowledge. Finding answers to Supabase questions is rarely difficult.

**Appwrite** has a passionate community with over 45,000 GitHub stars and strong representation in the Flutter, mobile, and non-JavaScript ecosystems. Appwrite's documentation is thorough, and the team ships new SDKs and runtime support at a fast pace. If your team builds mobile-first products, Appwrite's community will feel more relevant than Supabase's web-focused ecosystem.

**Nhost** has a smaller community (around 8,000 GitHub stars) but benefits from the broader Hasura ecosystem. Hasura's community is substantial, and most Hasura knowledge applies directly to Nhost deployments. The tradeoff is that Nhost-specific resources are thinner. You may find yourself reading Hasura documentation more than Nhost documentation.

### When to Choose Each Platform

**Choose Supabase self-hosted when:**

- Your team knows PostgreSQL and SQL well

- You want direct database access for analytics, reporting, or ad-hoc queries

- Vendor portability is a hard requirement

- You need advanced PostgreSQL extensions (pgvector, PostGIS, pg_cron)

- Your frontend is web-first (React, Next.js, SvelteKit, Nuxt)

**Choose Nhost self-hosted when:**

- Your frontend team uses GraphQL and already has a GraphQL client setup

- You want auto-generated, type-safe GraphQL APIs from your database schema

- Real-time subscriptions via GraphQL are a core requirement

- You are comfortable depending on Hasura as an infrastructure component

- You need PostgreSQL portability but prefer GraphQL over REST

**Choose Appwrite self-hosted when:**

- Your team builds for multiple platforms (Flutter, iOS, Android, web) and wants consistent SDKs

- You prefer a document-style API over raw SQL

- Built-in team management and multi-tenant permissions matter

- You want the simplest possible self-hosted setup experience

- Your data model is relatively flat and does not require complex relational queries

### What We Recommend

For most web applications with relational data models, **Supabase self-hosted** is our default recommendation. The PostgreSQL foundation, large community, strong migration story, and tight auth-to-database integration make it the safest long-term bet. Nhost is the right call when GraphQL is non-negotiable. Appwrite is the right call for mobile-first, multi-platform projects where SDK breadth and operational simplicity outweigh SQL access.

Whichever platform you choose, self-hosting is a commitment. You are signing up for database backups, security patches, monitoring, uptime management, and infrastructure scaling. If your team lacks DevOps capacity, starting on a managed tier and migrating to self-hosted later is a perfectly valid strategy.

Need help evaluating which self-hosted BaaS fits your product, or want a team that can deploy and manage the stack for you? [Book a free strategy call](/get-started) and we will walk through your architecture, data model, and infrastructure requirements together.

---

*Originally published on [Kanopy Labs](https://kanopylabs.com/blog/nhost-vs-appwrite-vs-supabase-self-hosted-baas)*