Nhost Alternatives: Keep Postgres, Choose Your API Style

The closest Nhost alternatives are StitchDB and Supabase, because both keep Postgres underneath and add Auth, Storage, Realtime and functions. If GraphQL is the part you can't give up, both also serve GraphQL from your schema, and Hasura itself can run on top of any Postgres. If you would rather leave SQL behind, Appwrite and Firebase are the document-style options. This guide compares the Nhost alternatives on the thing that makes Nhost distinct: a GraphQL-first API on Postgres.

#What Nhost gives you (as of November 2026)

Nhost bundles Postgres, the Hasura GraphQL engine (queries, mutations, subscriptions, event triggers and role-based permissions), Auth, Storage and Node.js serverless functions. It is MIT licensed and can be self-hosted with Docker Compose.

From nhost.io/pricing:

• Starter, $0: 1 GB database, 1 GB storage, 5 GB egress, 10 functions. Starter projects pause after one week of inactivity, and a free organization can have only one active project at a time.
• Pro, from $25/month with $15 of compute credits: 10 GB database, 50 GB storage, 50 GB egress, 7-day backups; point-in-time recovery from $100.
• Team, from $599/month, and custom Enterprise plans.
• Unlimited users on every plan, and usage above limits is billed rather than stopped.

That is a solid package. Teams look for an Nhost alternative mostly for three reasons: the free tier pausing, the jump between Pro and Team, or wanting REST and SQL policies rather than Hasura metadata.

#Summary

#GraphQL without Hasura: pg_graphql

StitchDB and Supabase both use pg_graphql, a Postgres extension that builds a GraphQL schema from your tables, views and foreign keys. On StitchDB you turn it on in Studio under API › GraphQL, and it answers at /graphql/v1:

curl https://<project-ref>.p.stitchdb.com/graphql/v1 \
  -H "apikey: $STITCHDB_ANON_KEY" \
  -H "Authorization: Bearer $USER_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"query":"{ todosCollection(first: 10) { edges { node { id title } } } }"}'

The naming differs from Hasura: a table todos becomes todosCollection with cursor paging, and mutations are insertIntotodosCollection, updatetodosCollection and deleteFromtodosCollection. Foreign keys become nested fields on both sides. Row level security applies to every query and mutation, exactly as on REST. See GraphQL.

What you do not get from pg_graphql: Hasura's remote schemas, actions and event triggers. Their usual replacements are Edge Functions for custom resolvers, and database webhooks for events on insert, update and delete.

#Translating Hasura permissions into RLS

Hasura permissions are defined per role in metadata. In Postgres backends, the same rule lives in the database as a policy. A typical Hasura select permission {"user_id": {"_eq": "X-Hasura-User-Id"}} becomes:

alter table public.todos enable row level security;

create policy "Users read their todos" on public.todos
  for select to authenticated
  using (user_id = auth.uid());

Custom session variables such as X-Hasura-Org-Id map to JWT claims. On StitchDB, a Customize access token Auth hook (a Postgres function) can add an org_id claim to every token, and policies read them with auth.jwt():

create policy "Org members read projects" on public.projects
  for select to authenticated
  using (org_id = (auth.jwt() ->> 'org_id')::uuid);

The advantage of RLS is that the same rule protects REST, GraphQL, Realtime and Storage, plus any direct connection that uses those roles.

#The alternatives

#StitchDB

A dedicated Postgres database per project with Auth, REST, GraphQL, Realtime, Storage (with image resizing and an S3 endpoint), Edge Functions on Deno, cron, queues and app services such as push notifications and feature flags. Free projects are not paused while you use your account; the Free plan's Auth and REST services sleep after 60 minutes without requests and wake within seconds.

Plans as of November 2026: Free $0 (500 MB database per project, 1 GB files, 25 GB egress, 50,000 MAU), Pro $15.99/month (10 GB database, 100 GB files, 1 TB egress, 100,000 MAU, 7 days of point-in-time recovery), Scale $49/month (20 GB database, 2 TB egress, 200,000 MAU, 14 days of recovery). Point-in-time recovery is included on every plan rather than an add-on. See pricing.

Trade-offs: EU-only regions (Germany and Finland), no self-hosted edition (Nhost has one), and functions run on Deno rather than Node.js. If you depend on Hasura actions or remote schemas, you will rewrite those.

#Supabase

Supabase is the larger open source Postgres backend, with pg_graphql for GraphQL, self-hosting, and 17 AWS regions. Free projects pause after a week of inactivity, like Nhost's. Pro is from $25/month (as of November 2026).

#Hasura on any Postgres

If Hasura is what you love, keep it and choose the database host separately. Hasura DDN has a free tier, Base from $5 per active model per month and Advanced from $30 per active model (as of November 2026), and the v2 engine is Apache 2.0 for self-hosting. Hasura connects to your database, so you can point it at a StitchDB or Supabase connection string. You will then handle auth and storage elsewhere.

#Appwrite and Firebase

If you are ready to leave SQL, Appwrite (open source, its own tables and documents API, functions in many runtimes) and Firebase (Firestore, mature mobile SDKs) are the document-style choices. Both are a bigger rewrite from Nhost than a Postgres backend.

#Feature checklist for Nhost users

Before you choose, list what your Nhost app actually uses and check each item:

If the right-hand columns cover your list, the move is mostly a translation exercise. If you depend heavily on actions, remote schemas or a large Hasura metadata file, keeping Hasura in front of a new Postgres host may be the smaller change.

#Moving off Nhost

Because Nhost is Postgres, the database move is the easy part. StitchDB's Import from Postgres copies tables, data, functions, triggers and sequences from any Postgres 12 or newer. When the source allows logical replication, it runs a live copy and you switch over in seconds; otherwise it does a one-time copy. Then:

1. Recreate Hasura permissions as RLS policies.
2. Move users. Check whether you can export their password hashes; if not, plan a password reset or magic-link sign-in for the first login.
3. Copy files from Nhost Storage into buckets.
4. Port functions from Node.js to Deno.serve handlers; npm: imports cover most packages.
5. Replace GraphQL queries one screen at a time, or keep GraphQL with pg_graphql.

See StitchDB vs Nhost for a side-by-side.

#FAQ

#Is Nhost open source?

Yes. The Nhost repository is MIT licensed and its README says the whole stack can be self-hosted.

#Does Supabase or StitchDB support GraphQL?

Yes. Both offer GraphQL through the pg_graphql extension, with row level security applied.

#Do Nhost free projects pause?

Yes. As of November 2026, Starter projects pause after one week of inactivity.

#Can I keep Hasura and move my database?

Yes. Hasura connects to any Postgres connection string. You would then pick separate services for auth and storage, or use a backend that includes them.

Keep Postgres and get REST, GraphQL and RLS in one project: try StitchDB free.