Hasura Alternatives: GraphQL on Postgres in 2026

The best Hasura alternatives depend on whether you need a GraphQL engine or a whole backend. If you want GraphQL generated from Postgres with no extra server, pg_graphql (built into StitchDB and Supabase) is the lightest option. If you want a standalone, extensible GraphQL server you run yourself, PostGraphile is the long-standing open source choice. If you want Hasura plus auth and storage in one package, Nhost bundles exactly that. And if GraphQL was only a means to an end, a REST API generated from your schema may be all you need.

#What Hasura is today (as of November 2026)

Hasura's current product is DDN, a GraphQL engine that connects to your existing data sources through connectors: PostgreSQL, MySQL, SQL Server, MongoDB, ClickHouse, Snowflake and others. It does not host your database. Pricing from hasura.io/pricing:

• DDN Free: $0, unlimited models, one supergraph developer, 15 minutes of observability data.
• DDN Base: from $5 per active model per month (a model accessed more than 1,000 times a month), unlimited developers, 30-day observability.
• DDN Advanced: from $30 per active model per month, adding federation and multi-team workflows.
• Enterprise: contact sales. Optional connector hosting is billed per vCPU-hour and GiB-hour.

The v2 GraphQL engine is Apache 2.0 open source, and the v3 engine and connectors are Apache 2.0 too. Hasura's strengths are real: one GraphQL API across many databases, a mature permission system, and federation for large organizations.

#Engine vs backend

Many teams adopt Hasura to avoid writing an API layer for a Postgres app, then discover they still need auth, file storage, background jobs and somewhere to run custom logic. Ask yourself which problem you have:

• "We have many data sources and want one graph." You need an engine: Hasura or a federation tool.
• "We have one Postgres database and want an API for our app." You need a backend, and GraphQL may or may not be the right shape.

#Comparison

#pg_graphql: GraphQL without a GraphQL server

pg_graphql runs inside Postgres. The schema is built from the tables, views and foreign keys in public and follows schema changes on its own; there is no metadata to keep in sync. On StitchDB you enable it in Studio under API › GraphQL and query /graphql/v1 with the same keys as the REST API.

A Hasura query like:

query {
  todos(where: { done: { _eq: false } }, limit: 10) {
    id
    title
    owner { email }
  }
}

looks like this with pg_graphql:

query {
  todosCollection(filter: { done: { eq: false } }, first: 10) {
    edges {
      node {
        id
        title
        profiles { email }
      }
    }
  }
}

(Both examples assume todos.owner_id is a foreign key to a profiles table.) The differences: collections end in Collection, paging is cursor based (first and after), results are wrapped in edges { node }, and related tables appear as nested fields named after the related table. Mutations are insertIntotodosCollection, updatetodosCollection and deleteFromtodosCollection, each returning affectedCount and records. Stable SQL functions become query fields and volatile ones become mutations. If you prefer Todos style names, turn on inflection once:

comment on schema public is '@graphql({"inflect_names": true})';

Permissions are not a separate layer. Row level security decides what each request can read and write, and a table only appears for a role that has privileges on it, so anon sees no insert mutation for a read-only table. See GraphQL.

What pg_graphql does not do: remote schemas, Hasura actions, event triggers, joining across databases, or federation. On StitchDB the usual replacements are Edge Functions for custom logic, database webhooks for events, and Postgres functions for computed results. A collection returns 30 rows per page by default; raise it with comment on schema public is '@graphql({"max_rows": 100})'.

#The alternatives in detail

#StitchDB

A dedicated Postgres database per project, with pg_graphql, a REST API, Auth, Realtime (Postgres changes, broadcast, presence), Storage and Edge Functions. Hasura subscriptions usually map to Realtime Postgres changes, which also respect RLS.

Plans as of November 2026: Free $0, Pro $15.99/month, Scale $49/month, Enterprise $329/month. GraphQL requests count as normal API requests of your plan. See pricing.

Trade-offs: only Postgres, only one database per API, EU-only regions (Germany and Finland), and no self-hosted edition. GraphQL rate limit rules do not apply to /graphql/v1 yet, per the docs. If you need a graph across many sources, Hasura is the better tool.

#Supabase

The same pg_graphql extension with Supabase's Auth, Storage and Realtime, 17 AWS regions and self-hosting. Free projects pause after a week of inactivity; Pro from $25/month (as of November 2026).

#PostGraphile

PostGraphile is crowd-funded open source software for building GraphQL APIs backed primarily by Postgres, now at V5. It runs as your own server, which makes it very extensible with plugins. Choose it if you want full control of the GraphQL layer and are happy to run and secure it yourself, together with separate auth and storage.

#Nhost

If you like Hasura's model and want auth, storage and functions around it, Nhost packages Postgres with the Hasura engine, MIT licensed and self-hostable. Starter is free and pauses after a week of inactivity; Pro from $25/month (as of November 2026). See Nhost alternatives.

#Plain REST from your schema

Both StitchDB and Supabase also generate a REST API from the same tables. For most app screens, a REST call with an embedded relation is as expressive as a GraphQL query:

const { data } = await stitchdb
  .from('todos')
  .select('id, title, profiles(email)')
  .eq('done', false)
  .limit(10)

If you mainly used Hasura to avoid writing CRUD endpoints, this may be simpler than keeping GraphQL. See instant REST API from your Postgres schema.

#Migrating Hasura permissions

The biggest job in leaving Hasura is usually permissions, not queries. A practical order:

1. Export the Hasura metadata and list every table with a select, insert, update or delete permission per role.
2. For each user role filter, write a policy with auth.uid() in place of X-Hasura-User-Id.
3. For column restrictions, use views that expose only the allowed columns, or column-level grant statements.
4. For custom session variables, add claims to the JWT with an Auth hook and read them with auth.jwt() ->> 'claim'.
5. Test each role with real tokens before switching traffic.

#Who should pick what

• Many databases, many teams, one graph: stay with Hasura DDN.
• One Postgres app, want GraphQL and a full backend: StitchDB or Supabase with pg_graphql.
• Want to own and extend the GraphQL server: PostGraphile.
• Want Hasura exactly, with auth and storage: Nhost.

#FAQ

#Is pg_graphql a replacement for Hasura?

For a single Postgres database with RLS, yes for queries, mutations and relations. It does not provide remote schemas, actions, event triggers or federation.

#Is Hasura open source?

The v2 engine is Apache 2.0, and the v3 engine and data connectors are intended to be Apache 2.0, per the Hasura repository.

#Does Hasura host my database?

No. Hasura connects to your existing databases through connectors.

#How does StitchDB handle GraphQL subscriptions?

Use Realtime Postgres changes on a channel for live updates; pg_graphql handles queries and mutations.

Get GraphQL and REST from one Postgres schema: start free on StitchDB.