Which PostgreSQL-to-GraphQL tool should you use in 2026: Hasura, PostGraphile, Supabase, PostgREST or Postrust?

Where a capability has a condition attached, the condition is in the cell. We make Postrust, so read its column with that in mind; each tool has a detailed page — Hasura, PostGraphile, Supabase and PostgREST — including where each is the better choice.

Which of these tools actually serve GraphQL?

Four of the five do. PostgREST serves REST only, and appears here because it is often named in the same breath and because two of the others build on its URL grammar.

Hasura, PostGraphile and Postrust are servers that read the schema and serve GraphQL themselves. Supabase is a platform — Postgres, auth, storage, realtime and a dashboard — whose GraphQL comes from the pg_graphql extension inside the database and whose REST API is PostgREST. Choosing Supabase is therefore less a choice of GraphQL generator than a choice of platform.

The GraphQL dialects are not interchangeable. Postrust deliberately speaks Hasura’s: a client generated against Hasura — its queries, its codegen output, its endpoint at /v1/graphql — points at Postrust unchanged. PostGraphile inflects names its own way and supports Relay conventions, which Postrust does not.

Where do permissions live: in the database or in metadata?

Hasura keeps permissions in its own metadata, per role and per field. PostGraphile, Supabase, PostgREST and Postrust leave them to PostgreSQL roles and row-level security, so every other client of the database is subject to the same rules.

The trade-off is real in both directions. Metadata permissions give Hasura a console to manage them and features such as inherited roles and remote-schema permissions. Database permissions mean there is no second copy of the rules to keep in sync, and a tool reading the schema needs no setup before the first query: what the connecting role is granted is what the API exposes. Hasura instead requires tables to be tracked and permissions declared.

Postrust supports both. It reads PostgreSQL roles and RLS, and it can also read Hasura’s permission model — a schema per role, row filters, separate read and write columns, presets and backend_only — from a JSON document you supply. It does not reach inherited roles or remote-schema permissions.

Which tools serve REST and GraphQL from the same tables?

Postrust serves both from one process: a PostgREST-compatible REST API and a Hasura-dialect GraphQL API. Supabase offers both as separate services of one platform; Hasura offers RESTified GraphQL endpoints; PostGraphile has no REST surface; PostgREST has no GraphQL.

For a SaaS team this matters when some clients want REST (webhooks, partners, simple scripts) and the front end wants GraphQL. Running PostgREST plus a GraphQL server is two deployments that must agree on permissions; RLS makes that agreement automatic, but the operations cost remains.

Which can be an Apollo Federation subgraph in October 2026?

Postrust and both Hasura products can; Supabase pg_graphql and PostGraphile V5 cannot, according to their own documentation and repositories. The details differ enough to matter.

• Postrust is an opt-in Federation v2 subgraph, enabled with PGRST_GRAPHQL_FEDERATION, where a table’s primary key is its @key. Apollo’s subgraph compatibility suite runs in CI; @requires, @provides, @override, non-primary keys and federated tracing are not supported yet, and Postrust is not on Apollo’s list of compatible subgraphs. See the Federation documentation.
• Hasura v2 is a subgraph for Federation v1 only, enabled globally and then table by table in metadata (source).
• Hasura DDN (v3) is documented as compliant with the subgraph specification, configured per object type and model; the docs name no Federation version, and other subgraphs cannot extend its types (source).
• PostGraphile: @graphile/federation for v4 is a proof of concept, last published in 2021 and unmaintained; we found nothing equivalent for V5 (source).
• Supabase pg_graphql has no Federation support, and its maintainers have said it is not planned (source).

A worked example with two databases behind Apollo Router is in PostgreSQL as an Apollo Federation subgraph.

What about GraphJin, Grafbase and IBM’s StepZen?

They also generate GraphQL over PostgreSQL, and this guide covers only where they stood on Federation in October 2026, from their own documentation.

• GraphJin serves Federation 2 SDL, but _entities is not implemented yet, so it composes and cannot resolve an entity another subgraph references (source).
• Grafbase’s Postgres extension runs inside Grafbase Gateway as a virtual subgraph; there is no server for Apollo Router to call (source).
• IBM API Connect for GraphQL (formerly StepZen) is on Apollo’s list of compatible subgraphs and reaches PostgreSQL through @dbquery; it is commercial, as SaaS or self-hosted software (source).

How do subscriptions differ between them?

Hasura treats subscriptions as a core feature, including cursor-based _stream. Postrust and PostGraphile build them on PostgreSQL’s LISTEN/NOTIFY; Supabase provides a separate Realtime service; PostgREST has none.

In Postrust each subscription field is a live query, served over WebSocket with the graphql-transport-ws protocol; _stream is not implemented. In PostGraphile you define the subscription fields yourself. On AWS Lambda Postrust serves GraphQL without subscriptions, because a function URL cannot hold a WebSocket.

How is each one deployed and hosted?

Postrust and PostgREST are single binaries, Hasura v2 runs as a container, PostGraphile runs on Node.js, pg_graphql is an extension inside the database, and Supabase is a managed platform or a stack you self-host.

Postrust is configured by environment variables rather than by state a server owns, and runs serverless as well as on servers: on AWS Lambda through a native adapter with the same REST and GraphQL API, and on Cloudflare Workers (see what the Worker serves). Hasura v2 is self-hostable as open source. Supabase is the only one here that is managed for you out of the box, with auth, storage and a dashboard included.

How closely does Postrust match Hasura and PostgREST, measured?

Compatibility is measured by replaying each project’s own tests against both servers, not asserted. The figures below are generated from those runs.

• Against Hasura v2.50.1, on 468 cases from Hasura’s own corpus, 97.4% agree at the “same data” level (same rows, or both refusing), measured 2026-10-11. Hasura conformance report.
• Against PostgREST v16.1, on 1499 of PostgREST’s own test cases, 96.8% agree on status and body, measured 2026-10-11. PostgREST conformance report.

Throughput comparisons are not published here at the moment: the comparison benchmark is being re-measured because its results did not reproduce reliably. The method is on the benchmarks page.

Which should a SaaS team choose, and when?

Choose by the constraint that matters most to you, not by a feature count. Each tool is the better fit for some teams, including the ones we do not make.

Choose Hasura when

• You need inherited roles or remote-schema permissions.
• Your API spans more than PostgreSQL: remote schemas and cross-source joins.
• You want event triggers, a console and the rest of a platform rather than a server. For new projects Hasura recommends v3 / DDN.

Choose PostGraphile when

• You want to reshape the generated GraphQL schema; its plugin system is built for that, and Postrust has no answer to it.
• Your team writes TypeScript and wants extensions in TypeScript.
• You want a Relay-compliant schema, and REST is not needed.

Choose Supabase when

• You want auth, storage, realtime and a dashboard without assembling them, and would rather not operate anything.
• You are early and want defaults that are already wired together.

Choose PostgREST when

• REST is all you need and a GraphQL surface would be weight.
• You want the full PostgREST surface and years of production use, documentation and community behind it.

Choose Postrust when

• You want REST and GraphQL over the same tables from one process, with permissions in PostgreSQL.
• You have Hasura clients and want to keep their queries while moving to a binary instead of a platform.
• You deploy to AWS Lambda, or want to add endpoints in Rust next to the generated API.

Postrust is young: a smaller surface and fewer users than any of the others here. Test the queries and endpoints you actually depend on before switching anything that matters.