Postrust vs Hasura
Hasura generates a GraphQL API from a PostgreSQL schema and models permissions as metadata rather than as database roles. It is a platform: a console, event triggers, remote schemas, and joins across more than one data source.
Postrust speaks Hasura's GraphQL dialect. A client generated against Hasura — its queries, its codegen output, its endpoint at `/v1/graphql` — points at Postrust unchanged, and the permission model comes with it: a schema per role, row filters, separate read and write columns, presets and `backend_only`. How closely the two agree is measured by replaying Hasura's own test corpus against both servers; the [conformance report](/docs/conformance/hasura) says what that covers and where they differ on purpose.
Postrust is still a smaller thing on purpose. It is one binary against one PostgreSQL, configured by environment variables rather than by state a server owns, and the permissions it reads are a document you supply rather than a console you operate.
- Hasura is written in
- Haskell
- Licence
- Apache 2.0 (v2 core engine)
- Version compared
- v2.50.1
- Their site
- hasura.io
Feature comparison
Where a capability has a condition attached, the condition is in the cell.
| Feature | Postrust | Hasura |
|---|---|---|
| GraphQL from the schema | Yes | Yes |
| GraphQL dialect | Hasura's, measured against it | Its own |
| REST API | Yes, PostgREST-compatible | RESTified GraphQL endpoints |
| Subscriptions | Live queries over LISTEN/NOTIFY; no _stream | Yes, a core feature, including _stream |
| Permissions | Hasura's model from a JSON document, or PostgreSQL roles and RLS | Metadata, per role and per field |
| Setup before first query | None. Tables are exposed on connect. | Tables must be tracked and permissions declared |
| Multiple data sources | PostgreSQL only | Yes, plus remote schemas and joins |
| Event triggers / webhooks | Not built in | Yes |
| Admin console | Admin UI with the admin-ui feature | Yes, extensive |
| Runtime | Single static binary | Container |
| License | MIT | Apache 2.0 for the v2 core engine |
When Hasura is the better choice
- You need the parts of the permission model Postrust does not reach: inherited roles, or remote-schema permissions.
- Your API spans more than PostgreSQL. Remote schemas and cross-source joins have no equivalent here.
- You want event triggers, a console for exploring and editing, and the rest of a platform rather than a server.
- You want a GraphQL implementation with a large user base behind it. Note that Hasura's own recommendation for new projects is v3 / DDN, which is a different product from the v2 engine compared here.
When Postrust fits better
- You want permissions to live in the database, where every other client is already subject to them.
- You would rather deploy a binary than operate a platform and its metadata.
- You need REST and GraphQL over the same tables without a translation layer between them.
Questions
Why does the benchmark compare against Hasura v2 rather than v3?
v2 is the self-hostable engine that runs as a single container against one PostgreSQL database, which is the closest comparison to Postrust. v3 / DDN is a different architecture and Hasura recommends it for new projects.
Will my existing Hasura queries work against Postrust?
That is the question the conformance harness exists to answer rather than assert. It replays Hasura's own test corpus against both servers on identically loaded databases and diffs the live responses; the report says what agrees, what does not, and which divergences are deliberate. Introspection is the largest known gap, and it is a limitation of the GraphQL library rather than of the dialect.
Does Postrust need tables tracked before they appear?
No. It reads the schema on connect, and what the connecting role is granted is what the API exposes. That is a smaller feature set than Hasura's metadata model, and it is also less to keep in sync.
Try it against your own schema
Point it at a database and see what it generates. That is a shorter path than reading a comparison table.