Nhost vs Supabase vs Appwrite (2026): Open-Source Backend Comparison for Postgres, GraphQL, Auth, and Pricing

If your team wants to move from day 1 to 10,000 users without pausing to babysit infrastructure, the choice of backend matters. This comparison looks at Nhost vs Supabase vs Appwrite through a GraphQL-first, Postgres-native lens, focusing on what changes as your product scales and you need zero-DevOps operations, precise authorization, and real extensibility. You will see how each platform handles a production-grade Postgres database, a real-time GraphQL API, authentication and authorization, storage/CDN, serverless logic, and pricing at scale—so you can ship faster with fewer surprises.

TL;DR—Who should choose what

• Choose Nhost if you want a GraphQL-first, Postgres-native stack with instant, typed, real-time GraphQL API, secure-by-default RLS, serverless functions, and the option to bring your own containers. It is a strong Firebase alternative for teams that want SQL, extensibility, and Git-based delivery.
• Choose Supabase if your team prefers a SQL-first developer experience with pg REST/RPC patterns and you are comfortable pairing the database with separate realtime and auth building blocks. Good for teams already fluent in Postgres and willing to stitch multiple services.
• Choose Appwrite if you want a general-purpose open-source BaaS with collection-centric data modeling and multi-runtime functions, and you are fine with less direct SQL and more SDK-driven development.

Short version of Nhost vs Supabase vs Appwrite: if your app structure is relational and you value an opinionated GraphQL API with production security and extensibility baked in, Nhost gets you to production rapidly and scales cleanly.

How we evaluate in 2026

We score what matters after the first release:

• Postgres modeling: native SQL, extensions, migrations, and branching
• GraphQL depth: schema generation, relations, subscriptions, computed fields
• AuthZ at the data layer: RLS, claims, field- and row-level controls
• Functions/containers: serverless ergonomics, eventing, bring-your-own services
• CI/CD: local parity, Git integration, preview environments
• Observability: logs, traces, metrics across DB, GraphQL API, and functions
• Pricing at scale: database size/IO, egress, invocations, realtime fan-out

Postgres, schema, and real-time

A production backend lives or dies by how it treats Postgres and subscriptions. Here is how Nhost vs Supabase vs Appwrite differ when you are modeling complex data and shipping real-time features.

Native SQL access

Nhost and Supabase both expose full Postgres with extensions, triggers, and views. That means complex joins, window functions, and extensions like PostGIS or pgvector fit naturally. Appwrite abstracts data as collections/documents; while that is approachable for simple apps, it reduces portability for SQL-heavy workloads and makes certain relational patterns harder.

Migrations and branching

Nhost treats schema as code: a Git-based pipeline applies SQL migrations with seed data to each environment and supports preview branches so reviewers see the real schema before merge. Supabase offers a solid CLI and SQL migrations with good team workflows. Appwrite leans console/SDK-first and requires more manual discipline to keep environments aligned for large teams.

Realtime on Postgres

Nhost provides instant real-time GraphQL subscriptions over Postgres with row/column filters, combining precision and performance. Supabase offers realtime channels (logical replication) that work well but live separately from its GraphQL. Appwrite emits realtime events at the collection level; it is straightforward but less expressive for relational filters and cross-table updates.

GraphQL API depth and ergonomics

All three can serve an API quickly, but the path to a safe, typed, scalable GraphQL API varies.

Schema generation

Nhost auto-generates a rich GraphQL API directly from Postgres: tables, relations, enums, views, and computed fields become first-class, typed operations. The schema reflects constraints and indexes, so performance hints are preserved. Supabase supports GraphQL via pg_graphql, which is powerful but requires more manual tuning. Appwrite provides GraphQL on top of collections; it is useful for CRUD but less natural for deep relational traversals.

Subscriptions and live queries

Nhost offers first-class GraphQL subscriptions with fine-grained filters, delivering minimal payloads and predictable latency. Supabase typically pairs REST/RPC or GraphQL with separate realtime listeners, adding client complexity. Appwrite uses event subscriptions per collection; good for broad updates, but not as targeted for complex joins.

Field- and row-level rules

Nhost maps JWT claims into Postgres RLS and enforces access at the row and field level through the GraphQL API, so you express policy once at the data layer. Supabase also leans on RLS effectively. Appwrite permission rules live at the collection/document level; achieving field-level parity generally requires additional app logic.

Authentication and authorization

Auth should connect cleanly to your data rules and service-to-service flows—without building a custom auth service.

Providers and tokens

Nhost ships email/password, OTP, OAuth providers, and magic links. Issued JWTs include claims for roles and tenant scopes, so the GraphQL API and RLS work in lockstep. Supabase is similar in providers and JWT flows. Appwrite uses sessions and API keys with permissions at the document level; it works, but claims rarely drive SQL rules because SQL is abstracted.

If you are building AI or agentic flows that need delegated access, see How to Add OAuth2 and JWT Authentication to Your AI Agents (Step-by-Step Guide) for a practical pattern you can apply on Nhost today.

RLS and role policies

Nhost defaults to Postgres RLS with roles and session variables injected from the JWT, keeping sensitive logic server-side and auditable. Supabase mirrors this well. Appwrite relies on per-collection and per-document permissions; it is clear and SDK-friendly but not as granular at the SQL row/column level.

Multi-tenant patterns

Nhost recommends org- and user-scoped claims in JWTs, making tenant isolation a single policy, not a pile of middleware. Supabase supports a comparable pattern with RLS. Appwrite can implement tenancy with collection permissions, but cross-tenant constraints and aggregate queries need more composition.

Storage and CDN

From profile images to multi-GB media, storage and egress economics can define your bill—and your user experience.

Access rules

Nhost storage integrates with auth claims and RLS-like policies so file access mirrors your data model. Signed URLs are straightforward, and the GraphQL API can coordinate uploads with app logic. Supabase storage uses SQL-backed bucket policies and signed URLs effectively. Appwrite permissions are defined at the file/bucket level; consistent, but mapping to row-level data policies can take extra steps.

Performance at scale

Nhost puts a global CDN in front of storage, supports resumable and multipart uploads, and surfaces metrics to help you watch egress. Supabase offers similar primitives; both are strong choices for media-heavy apps. Appwrite performs well but tuning CDN behavior and edge caching may require additional configuration depending on your plan.

Functions and extensibility

As requirements grow, you will need custom logic, integrations, and background processing—without managing servers.

Serverless JS/TS functions

Nhost provides serverless functions in JavaScript/TypeScript with zero-config deploys tied to your Git workflow, sharing auth context and environment secrets with your GraphQL API. Supabase offers Edge Functions (Deno) with solid DX and fast cold starts. Appwrite Cloud Functions support multiple runtimes, which is flexible, though you will manage more knobs per function.

Bring your own containers

Nhost lets you deploy custom services in containers alongside your backend—any language, any framework. That means running a Python ML microservice or a Go event processor next to your Postgres and GraphQL API, with first-class networking and observability. Supabase and Appwrite focus primarily on their function runtimes; containerized services usually require external infra.

Background jobs and schedules

Nhost supports cron schedules, queues, and database/event triggers with configurable retries and concurrency. Supabase offers database-triggered functions and scheduling options; robust but spread across components. Appwrite provides scheduled functions and webhooks; scale characteristics vary by deployment size.

AI toolkit and events

Modern apps mix transactional data with embeddings, vector search, and event-driven orchestration. Here is how Nhost vs Supabase vs Appwrite handle it.

Vectors and embeddings

Nhost supports vectors via Postgres extensions like pgvector and exposes them through the GraphQL API, keeping embeddings next to your primary data and under the same RLS policies. Supabase also has mature pgvector support. Appwrite can store embeddings in documents or route to external vector stores; workable, but less cohesive for relational joins with vector similarity.

Secure model calls

Nhost functions and containers can call model providers with user-scoped JWT context and audit trails, so you preserve least-privilege. Supabase and Appwrite can implement similar patterns, but often require more custom glue. For a step-by-step approach to delegated access in AI agents, see How to Add OAuth2 and JWT Authentication to Your AI Agents (Step-by-Step Guide).

DevEx: local to prod with Git

Winning teams depend on reproducible environments and fast feedback loops.

CLI and local parity

Nhost CLI spins up Postgres, the GraphQL API, authentication, storage, and functions locally with Docker, mirroring production behavior closely. Supabase CLI has strong local dev as well. Appwrite centers on its server runtime locally; it works but aligning local and cloud setups for large teams may take additional effort.

CI/CD and previews

Nhost ties deployments to Git: schema migrations, seed data, and serverless/functions ship on push, with preview environments for every PR. Supabase supports migration pipelines and automated deploys; previews vary by setup. Appwrite CI often relies on SDK scripts or infrastructure-as-code to synchronize environments.

Observability

Nhost centralizes logs, traces, and metrics across Postgres, the GraphQL API, storage, and functions/containers for fast incident response. Supabase offers observability features with differences by plan and via external tools. Appwrite provides logs and metrics; depth and retention depend on your deployment and tier.

Pricing and scaling realities

All three are cost-efficient early on. At scale, usage patterns dominate: database IO, function invocations, and especially storage egress.

Free tiers and overages

Nhost uses transparent usage buckets across database, storage, and compute so you can forecast growth. Supabase has generous free tiers; watch function and realtime usage as traffic grows. Appwrite Cloud pricing maps to allocated resources; model spikes and autoscaling behavior for production.

Egress and CDN

Media-heavy products pay the most on egress across Nhost vs Supabase vs Appwrite. Nhost ships CDN optimizations and caching controls that reduce origin hits, but you should still budget for peak traffic and global audiences.

Performance at scale

Nhost scales vertically and horizontally with connection pooling, read replicas, and workload isolation for functions/containers. Supabase provides autoscaling Postgres and caching layers. Appwrite scales with resource-based tiers; ensure headroom for hotspots like event fan-out.

Security, compliance, and enterprise

Regulated teams need more than features—they need auditable controls that keep pace with growth.

Compliance and networking

Nhost offers SOC 2, automated backups, private networking and peering options, and granular access controls. Validate comparable offerings and limits on Supabase and Appwrite for your intended tier and region coverage.

SSO and org controls

Nhost supports SSO/SAML, org-wide roles, and audit logs that span the GraphQL API and services. Ensure parity on competing plans if you need least-privilege and traceability across teams and environments.

Firebase alternative: where each fits

If you are seeking an open-source BaaS and a credible Firebase alternative:

• Nhost: SQL-first, GraphQL API by default, real-time, and extensible with serverless plus bring-your-own containers; best when your model is relational and you want to avoid lock-in.
• Supabase: SQL-first with REST/RPC and optional GraphQL; excellent for teams already standardized on Postgres tooling.
• Appwrite: General-purpose open-source BaaS with document-style collections; approachable for CRUD apps that prefer SDK-driven development.

Migration and portability

Your future self will thank you for choosing a path with easy exits.

Supabase to Nhost

Export Postgres schema and data, carry over your RLS policies, and turn on Nhost’s auto-generated GraphQL API. Map Edge Functions to Nhost serverless functions or containers. Client apps usually need minimal changes other than pointing to the new GraphQL endpoint and auth domain.

Appwrite to Nhost

Transform collections/documents into normalized Postgres tables, reapply permissions as RLS, and swap SDK calls for GraphQL queries/mutations plus signed URL storage flows. Background tasks move into Nhost functions or long-running containers where needed.

Example stacks by use case

Copy these blueprints to accelerate delivery on Nhost.

Indie SaaS

• Data: Postgres tables with tenant_id columns and RLS policies
• API: Nhost GraphQL API for CRUD and relations
• Auth: OAuth + email/password with role claims
• Storage: Signed uploads for invoices and avatars
• Functions: Webhooks for billing and metering

Realtime collaboration

• Data: Documents, comments, presence tables
• API: GraphQL subscriptions for presence, cursors, and edits
• Storage: Asset uploads with CDN delivery
• Extensibility: Containerized OT/CRDT service alongside GraphQL

AI app

• Data: pgvector for embeddings stored with content metadata
• API: GraphQL API for search and scoped content retrieval
• Auth: JWT claims for per-user and per-organization limits
• Functions/containers: LLM orchestration with secure provider calls and event-driven pipelines

Decision checklist

• Do you want a GraphQL-first experience with instant schema and subscriptions?
• Will your data model need native Postgres features and extensions?
• Do you require RLS-backed row and field security rather than app-layer checks?
• Do you need extensibility beyond functions—like bring-your-own containers?
• Does your team rely on Git-based CI/CD, previews, and local parity?
• Are your workloads sensitive to egress and invocation costs at scale?
• Do you have compliance, SSO/SAML, or private networking requirements?

Why Nhost? For teams that want a production-ready, open-source BaaS with a best-in-class GraphQL API on Postgres, secure-by-default authz, storage with CDN, serverless functions, and the option to bring your own containers, Nhost balances speed today with flexibility tomorrow.

Get started for free and ship your next release with less infrastructure, more product.

Frequently Asked Questions

Is Nhost a Firebase alternative and open-source BaaS?

Yes. Nhost is a managed, open-source–based stack built on Postgres with an instant GraphQL API, authentication, storage, and functions. It is a strong Firebase alternative when you want SQL and GraphQL at the core instead of a proprietary document store.

Does Nhost support REST if my team isn’t ready for GraphQL?

Yes. You can expose REST endpoints derived from predefined GraphQL operations, retaining the same authentication and RLS guarantees while your team adopts GraphQL at its own pace.

How hard is it to migrate from Supabase to Nhost?

Typically straightforward. Export your Postgres schema and data, carry over RLS policies, enable Nhost’s auto-generated GraphQL API, and port Edge Functions to Nhost serverless functions or containers. Client updates are usually limited to endpoints and auth domains.

What about bring-your-own containers—why does it matter?

It lets you run any language or runtime—such as a Python ML service or a Go event processor—right next to your GraphQL API and database without standing up separate infrastructure. This reduces latency, complexity, and operational overhead.

How do pricing dynamics differ at scale?

All three platforms meter storage, egress, and compute. On Nhost, the main levers are database/storage usage and function/container compute. Regardless of provider, you should model media egress and function invocations early to avoid surprises.