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 is a smaller thing on purpose. Permissions stay in PostgreSQL as roles and row-level security, and configuration stays as environment variables rather than as state a server owns.
- Hasura is written in
- Haskell
- Licence
- Apache 2.0 (v2 core engine)
- Version compared
- v2.44.0
- 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 |
| REST API | Yes, PostgREST-compatible | RESTified GraphQL endpoints |
| Subscriptions | Over LISTEN/NOTIFY | Yes, a core feature |
| Permissions | 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 |
Measured performance
Produced by scripts/bench-compare.sh, which starts both servers as containers against the same database and runs the same load against each. Where Hasura is faster, that is what the table says.
GraphQL
| Scenario | Postrust req/s | Hasura req/s | Postrust p95 | Hasura p95 | Difference |
|---|---|---|---|---|---|
| single row by primary key | 12,440 | 4,535 | 5.1 ms | 44 ms | 2.7× faster |
| 25-row page | 8,477 | 4,907 | 7 ms | 17.4 ms | 1.7× faster |
| 25-row page + embed | 5,193 | 3,588 | 11.4 ms | 20 ms | 1.4× faster |
Image size and memory
| Postrust | Hasura | |
|---|---|---|
| Container image, on disk | 168MB | 711MB |
| Memory, before serving a request | 1.9 MB | 167.9 MB |
| Memory, after the benchmark | 14.8 MB | 198.9 MB |
Memory is resident set size, read the same way for every tool. Image sizes are for the Debian-based build these figures come from. The Alpine build of the same code is 31.7MB.
How this was measured
- Every server runs as a container on one docker network against the same PostgreSQL instance and the same dataset. No tool gets to skip container overhead.
- Each tool keeps its own default connection pool and worker settings. Tuning one and not the others measures the tuning, not the tool.
- Requests are expressed in each tool's own dialect, because the dialects differ. The work asked of PostgreSQL is the same.
- Every target is warmed before any of them is measured, and the database cache is populated first, so no tool pays to warm the cache for the ones measured after it.
- Each figure is the median of several runs rather than the best of them, because a best-of-N reports whichever tool got the quietest moment on the machine.
- These are single-machine numbers from a laptop. They are useful for comparing the tools against each other, not for capacity planning.
Darwin 25.2.0 arm64 · PostgreSQL postgres:16 · bench_items 100000 rows, bench_reviews 300000 rows · 3000 requests at concurrency 50, median of 5 runs after 500 warm-up requests. Full benchmark method
When Hasura is the better choice
- You need permissions expressed per role and per field without modelling them as database roles and RLS policies.
- 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.
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.