StitchDB vs Nhost: Two Postgres Backends, Different API Layers

StitchDB and Nhost both put Postgres at the center and add Auth, Storage and serverless functions, so your data model can be the same on either. The difference is the layer on top. Nhost is GraphQL-first through the Hasura engine, with Hasura permissions and event triggers, Node.js functions, and an open source stack you can self-host. StitchDB generates REST from your schema (plus GraphQL through pg_graphql), puts access rules in Postgres row level security, runs Deno functions, and adds app services such as push and offline sync. If your team lives in Hasura, Nhost is the natural home; if you prefer REST and SQL policies, StitchDB is.

#Comparison table

NhostStitchDB
DatabasePostgresPostgres, one dedicated database per project
Primary APIGraphQL (Hasura): queries, mutations, subscriptionsREST (PostgREST-compatible) from your schema
GraphQLHasura enginepg_graphql at /graphql/v1
Access rulesHasura role-based permissionsPostgres row level security
EventsHasura event triggersDatabase webhooks, triggers, pg_net, queues
FunctionsNode.js (JavaScript/TypeScript)Deno (TypeScript/JavaScript)
Free tier (as of November 2026)Starter $0: 1 GB DB, 1 GB storage, 5 GB egress; pauses after 1 week inactive; one active free projectFree $0: 2 projects, 500 MB DB each, 1 GB files, 25 GB egress; not paused while the account is used
Entry paidPro from $25/mo with $15 compute creditsPro $15.99/mo
Point-in-time recoveryFrom $100 (Pro and Team)Included: 24 h Free, 7 days Pro, 14 days Scale, 30 days Enterprise
UsersUnlimited on every plan50K / 100K / 200K MAU included, then per MAU
Self-hostYes (MIT)No
RegionsNhost cloudEU only (Germany, Finland)

Nhost figures come from nhost.io/pricing; StitchDB's from pricing.

#Five questions that decide it

#1. Do you want GraphQL or REST as your main API?

With Nhost, GraphQL is the way your app talks to data. Hasura's engine gives you rich filtering, aggregations, subscriptions over GraphQL, and remote schemas or actions to stitch in other services.

With StitchDB, every table and view is a REST endpoint, and the SDK reads like a query builder:

JavaScript
const { data } = await stitchdb
  .from('invoices')
  .select('id, total, customers(name)')
  .gte('created_at', '2026-10-01')
  .order('created_at', { ascending: false })
  .range(0, 49)

GraphQL is there if you want it: turn on pg_graphql in Studio and query todosCollection-style fields with RLS applied. It does not have Hasura's remote schemas, actions or event triggers; see GraphQL.

#2. Where should access rules live?

Hasura permissions are configured per role and table in metadata, using session variables such as X-Hasura-User-Id. They protect the GraphQL API.

StitchDB policies live in the database and protect REST, GraphQL, Realtime and Storage at once:

SQL
alter table public.invoices enable row level security;

create policy "org members read invoices" on public.invoices
  for select to authenticated
  using (org_id in (select org_id from public.memberships where user_id = auth.uid()));

If you also connect BI tools or workers directly to Postgres, keeping rules in the database means one rule set. If your rules are mostly about shaping a GraphQL API, Hasura's model is very productive.

#3. Node.js or Deno for functions?

Nhost functions are Node.js. StitchDB Edge Functions use Deno.serve with npm: and jsr: imports, so most npm packages work, but Node-specific APIs that need native modules or spawning processes do not. Both handle the usual jobs: webhooks, payments, e-mail, AI calls.

StitchDB adds background jobs for durable multi-step work and pg_cron for schedules inside the database.

#4. How do the free tiers behave?

Nhost Starter projects pause after a week without activity, and a free organization can run one active project at a time. StitchDB Free projects are not paused while you use your account (signing in or any API or database use counts); only accounts abandoned for a year are paused, after two e-mails. On StitchDB Free, Auth and REST services sleep after 60 minutes without requests and wake within a few seconds; the database stays up. See pricing for the full plan limits.

#5. Must you be able to self-host?

Nhost is MIT licensed, and its README says the whole stack can be self-hosted, with a docker-compose example. StitchDB has no self-hosted edition. It offers a full project export on every plan instead, and its APIs are compatible with the open-source Supabase stack.

#Costs at small and medium scale

At the low end, both are free; the main difference is pausing. At the first paid tier (as of November 2026):

  • Nhost Pro from $25/month with $15 of compute credits, 10 GB database, 50 GB storage, 50 GB egress, 7-day backups, unlimited users. Point-in-time recovery from $100.
  • StitchDB Pro $15.99/month with a 10 GB database, 100 GB files, 1 TB egress, 100,000 MAU, 7 days of point-in-time recovery and 3 preview branches per project.

Nhost's unlimited users are an advantage for apps with many signed-in but low-traffic users. StitchDB's included egress and recovery are larger at the entry tier. Above Pro, Nhost's next tier is Team from $599/month; StitchDB's are Scale at $49 and Enterprise at $329.

#What StitchDB adds beyond the core

Things Nhost users often build or buy separately, included in StitchDB projects:

  • Push notifications to iOS, Android and the web, with an in-app inbox.
  • Offline sync with per-table conflict rules in the JS, Flutter, Swift and Kotlin SDKs.
  • In-app purchase checks, Stripe sync, feature flags, crash reporting, analytics, short links and status pages.
  • AI agent keys with a query firewall, approvals and per-session undo, and an MCP server.

#Moving from Nhost to StitchDB

Both are Postgres, so the move is mostly mechanical:

  1. In a new StitchDB project, open Database › Import from Postgres and paste Nhost's direct connection string. The import copies tables, data, views, functions, triggers and sequences, and runs a live copy when the source allows logical replication; otherwise a one-time copy. See import.
  2. Translate Hasura permissions into RLS policies, table by table.
  3. Replace event triggers with database webhooks or triggers.
  4. Port Node.js functions to Deno.
  5. Switch client calls from GraphQL to the SDK, or keep GraphQL via pg_graphql.

#Local development

Nhost's CLI runs the stack locally for development. StitchDB's stitchdb start runs Postgres, Auth, REST, Realtime, Storage, Edge Functions, a local Studio and a mail catcher as native processes, without Docker. Each folder or git worktree gets its own local project and ports, so two branches (or two coding agents) can run side by side. Migrations live in stitchdb/migrations/ and go to the hosted project with stitchdb db push, which warns about statements that would lock a busy table.

#Verdict

Nhost is the better fit if Hasura is central to how you build, you need self-hosting, or you want unlimited users with no MAU pricing.

StitchDB is the better fit if you want REST and SQL policies, point-in-time recovery without an add-on, no pausing on the free tier, EU hosting, and app services like push and offline sync in the same project.

See also Nhost alternatives and Hasura alternatives.

#FAQ

#Is Nhost the same as Supabase?

No. Both use Postgres, but Nhost's API layer is Hasura GraphQL, while Supabase (like StitchDB) generates REST with PostgREST and offers GraphQL via pg_graphql.

#Can I use Hasura with StitchDB?

Hasura connects to Postgres connection strings, so you can point it at a StitchDB database. You would manage Hasura separately.

#Do Nhost free projects pause?

Yes, after one week of inactivity as of November 2026. StitchDB Free projects do not pause while the account is in use.

#Does StitchDB support GraphQL subscriptions?

Use Realtime Postgres changes for live updates. pg_graphql covers queries and mutations.

Bring your Postgres schema and keep your data model: start free on StitchDB.