Hasura GraphQL Engine: Instant GraphQL APIs on Your Database

What the Hasura GraphQL Engine Solves

Building a GraphQL API manually requires writing type definitions, resolver functions, and data-fetching logic for every field. The Hasura GraphQL Engine removes that work: it connects to a database, reads the schema, and exposes a fully typed GraphQL API automatically. The README describes the engine as providing access to data via a single, composable, secure API endpoint.

The target users are teams that already have a relational or document database and need a GraphQL interface without the overhead of maintaining hand-written resolvers. The engine also adds capabilities that go beyond a simple API wrapper: real-time data via GraphQL subscriptions, event triggers that fire webhooks on database changes, and a role-based access control system for fine-grained permissions on queries and mutations.

V2 and V3: Two Engines in One Repository

The repository is structured as a mono-repo containing two distinct engine generations. V2 is the current stable version, documented in the v2/ folder and the V2-README.md. V3, which powers Hasura DDN (Data Delivery Network), is in the v3/ folder. The README notes that V3 went GA with support for PostgreSQL and its variants, MongoDB, ClickHouse, and MS SQL Server, along with TypeScript, Python, and Go Connector SDKs for custom business logic.

The two engines are architecturally different. V2 is a Haskell service that reads the database schema and generates GraphQL directly. V3 uses a connector-based architecture where each data source is accessed through a Data Connector that implements a defined specification. All Hasura connectors for V3 are also available open source through a Connector Hub listed at hasura.io/connectors/.

Current releases are versioned under V2: the most recent is v2.50.3, published on 2026-09-09.

Running Hasura with Docker Compose

The repository includes a docker-compose.yaml for local development. The Makefile documents the standard workflow:

docker compose up -d

This starts all services in the background, including a PostgreSQL instance configured with the hasura user, password, and database. The services section in docker-compose.yaml names the PostgreSQL service with ports at 65002:5432 to avoid conflicting with existing local instances. The README notes that if database init scripts are changed, the volumes should be removed with:

docker compose down -v

Otherwise PostgreSQL skips re-initialization on an existing database. The credentials used in the docker-compose setup for PostgreSQL are all set to hasura to minimize configuration overhead during development.

Cloning a Repository This Large

The Hasura repository is described in the README as a large and active mono-repo with a long git history. A full clone is slow and disk-intensive. The README provides two alternatives.

A shallow clone that downloads only the latest commit:

git clone https://github.com/hasura/graphql-engine.git --depth 1

A sparse checkout that downloads only the V3 engine code:

git clone --no-checkout https://github.com/hasura/graphql-engine.git --depth 1
cd graphql-engine
git sparse-checkout init --cone
git sparse-checkout set v3
git checkout @

The sparse checkout approach is useful for contributors who only work on the V3 engine and do not need the console, CLI, server, or community directories that make up the bulk of the repository.

Access Control and Webhook Event Triggers

Two features make Hasura useful beyond simple data proxying. The first is access control. The engine supports role-based permissions that operate at the row and column level. A developer role, for example, can be configured to see only rows in a table where a user_id column matches the calling user's identity. These rules are defined in metadata, not in application code.

The second is event triggers. The README description calls this out: the engine can trigger webhooks on database events. When a row is inserted, updated, or deleted, Hasura can call an external HTTP endpoint. This creates an event-driven architecture without requiring the application to implement change-data-capture logic directly. The documentation for event triggers is linked from the project's Discord community and the hasura.io documentation site.

Limitations: Schema-First Design and Vendor-Specific Features

Hasura's strength, auto-generating from the schema, is also a constraint. The resulting GraphQL API mirrors the database structure. Teams that want a GraphQL API with a different shape from the database schema, for example aggregating multiple tables into a single type or exposing computed fields with complex logic, must use remote schemas or custom actions (V2) or the connector SDK (V3).

A second limitation is that some features differ between V2 and V3. The README notes that V2 is the current stable version and V3 is the new architecture. Teams evaluating Hasura need to determine which engine generation matches their database and deployment requirements, as migration between them is not trivial.

The repository's dual licence structure in V2 adds complexity: the core GraphQL engine server is Apache-2.0, while the contents of the docs/ and community/ directories are MIT. The V3 engine is also intended as Apache-2.0. Teams using content from the repository for internal documentation or tooling should verify which directory their content originates from.

Hasura versus Apollo Server: Generated versus Hand-Written APIs

Apollo Server is a JavaScript GraphQL server that requires developers to write their own schema definitions and resolver functions. It gives full control over the API shape and data-fetching logic but requires significant upfront development work.

Hasura generates the API automatically from the database schema, which reduces initial development time to near zero for standard CRUD operations. The trade-off is that the API shape is tied to the database structure. PostgREST is another auto-generating API layer for PostgreSQL, but it generates REST endpoints, not GraphQL, and does not support real-time subscriptions or event triggers. For teams that specifically need GraphQL with subscriptions on a supported database and want to avoid resolver code, Hasura is the more direct path than Apollo Server.

Maintenance, Licensing, and Support Channels

Hasura GraphQL Engine is under active development. The last push was on 2026-09-21 and v2.50.3 was released on 2026-09-09. V2 is Apache-2.0 for the core engine; other V2 content outside the server, CLI, and console directories is MIT-licensed. V3 is intended to be Apache-2.0.

Support channels include Discord at discord.gg/hasura, GitHub issues for bug tracking, and the DDN documentation at hasura.io/docs/3.0/ for V3 or hasura.io/docs/ for V2. The repository has a CODE_OF_CONDUCT.md and SECURITY.md for reporting security issues privately. A Makefile target list, accessible via make help, lists the available development operations.

Editorial conclusion

Hasura GraphQL Engine is well suited for teams that need a GraphQL API on an existing database and want to avoid writing resolver code. The auto-generated schema follows the database structure, which reduces the initial development burden but also means the API shape is constrained by the schema rather than by application requirements. V2 is the stable production option for teams on PostgreSQL or other supported databases; V3 and Hasura DDN is the direction for new deployments that need the TypeScript, Python, or Go connector SDK for custom business logic. Before adopting, verify that your target database is in the supported connector list, since adding an unsupported data source requires writing a connector using the SDK.

Frequently asked questions

Official sources

1. hasura/graphql-engine on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases