Hasura

Last reviewed Sep 13, 2026 · 886 words

Five minutes from docker compose up to a working GraphQL API with queries, mutations, and live subscriptions over your existing Postgres tables. That is the Hasura pitch and, unusually, it is literally true: the engine reads your schema, generates the API, and hands you a console to point and click through relationships. The catch arrives at minute six, when you realise that an API which exposes every table to anyone holding the URL is not an API you can ship, and the real work of Hasura is the permission system.

The instant API is real and it is fast

Hasura compiles a GraphQL query into a single SQL statement rather than resolving field by field, which is why a nested query across 4 tables comes back in one round trip instead of the N+1 cascade that hand-written resolvers tend to produce. Subscriptions work the same way, polling the database on a short interval and multiplexing identical queries across clients, so 500 dashboards watching the same table cost roughly one query per tick rather than 500. On a 512 MB container it comfortably serves a small application; the database is where your resources actually go.

services:
  hasura:
    image: hasura/graphql-engine:latest   # pin to the v2.x tag you tested
    ports:
      - "8080:8080"
    environment:
      HASURA_GRAPHQL_DATABASE_URL: postgres://hasura:secret@db:5432/app
      HASURA_GRAPHQL_ADMIN_SECRET: change-me-now
      HASURA_GRAPHQL_ENABLE_CONSOLE: "true"
    restart: unless-stopped

Replace latest with the exact v2.x tag you tested before this goes anywhere real; the v2 line is stable and you want upgrades to be a decision. Set the admin secret before the first start, because without it the console and the full API are open to anyone who can reach port 8080.

Permissions are where the real time goes

Hasura's access control is role-based and row-level: for each table and each role you declare which columns are visible and a boolean expression over the row, usually comparing a column to a session variable like X-Hasura-User-Id. Those session variables come from a JWT you issue elsewhere or from a webhook Hasura calls on every request. This is genuinely fine-grained and it lives in metadata, not in your application code, which is either the best or the worst part depending on your team. The trap is that the default is nothing: a new table has no permissions for any non-admin role, and the temptation under deadline is to grant select on everything to the user role and move on. Write the row filters on day one, export the metadata with the CLI, and commit it alongside your migrations.

Event triggers replace a queue for small systems

Every insert, update, or delete on a tracked table can fire a webhook with the old and new row, with retries and a delivery log. For a self-hosted app this quietly replaces a message queue and a worker: an order row appears, Hasura posts it to an n8n workflow or a tiny HTTP handler, and you are done. Actions let you bolt custom business logic onto the same graph as REST endpoints, and remote schemas stitch in another GraphQL service. None of this needs the paid tier.

What the free engine does not include

The Apache-2.0 core engine is complete for building an application. The features behind the enterprise licence are the operational ones: query response caching, read replica routing, rate limiting, detailed observability integrations, and some of the security tooling. A homelab or a small product will not miss them. The other thing to know is direction: Hasura's development focus has moved to its v3 platform, Hasura DDN, which is a different architecture with its own tooling and a hosted-first story. The v2 engine you would self-host still receives releases, but the new features are landing elsewhere. That is not a reason to avoid it. It is a reason to treat v2 as a mature tool rather than an evolving one.

Postgres-centric, and that is a feature

Hasura's best experience is on Postgres, and the design assumes you are happy to keep your data there. If you are, the Postgres for everything argument applies: one database, one backup, one thing to learn. If your requirements are broader than an API layer, the comparison to make is with Supabase, which bundles Postgres, auth, storage, and its own PostgREST-based API, or with Directus, which gives you a REST and GraphQL layer plus a full admin interface for non-developers. Hasura wins on GraphQL depth and subscription performance; Supabase wins on being a whole backend. The dev-tools category has the wider field.

What I'd do

For an existing Postgres schema that needs a typed API for a frontend, I would pick Hasura v2, pin the version, set the admin secret, and spend the first afternoon on permissions and metadata export rather than on the console's autocomplete. For a new project with no database yet, I would start with Supabase instead, because auth and storage are the parts you will otherwise end up building around Hasura by hand. Either way, keep the metadata in git; the day you rebuild the container is the day you find out whether you did.