Hasura GraphQL Engine: one endpoint over Postgres, MongoDB, ClickHouse and SQL Server, with v2 and v3 living in the same repo
Blazing fast, instant realtime GraphQL APIs on all your data with fine grained access control, also trigger webhooks on database events.
At a glance
- What is it?
- The repository now carries two engines: a stable v2 in the v2 folder and the DDN-era v3 in the v3 folder, each with different licensing scope and different data source support. This is what the README supports, and where it stops.
- Who is it for?
- Adopt Hasura if you need one GraphQL endpoint in front of an existing relational database with row and column level access rules, and you are willing to run a server process next to that database. Do not adopt it if you cannot accept that the README gives no v2 quickstart and no v3 self-hosting instructions, or if you need a data source outside the set the v3 README names.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 7 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
Two engines in one repository, and the README treats them as separate products
The single most important thing about this repository is that it is not one engine. The README splits the project into Hasura V3 and Hasura V2 and points at different folders for each: v3 README for the DDN engine, V2-README.md for the stable release. The v3 engine is described as the code that powers Hasura DDN, and the README says it supports PostgreSQL and its flavours, MongoDB, ClickHouse and MS SQL Server, plus custom business logic written against TypeScript, Python and Go Connector SDKs. V2 is described as the current stable version. Those two sentences do not describe the same product, and anyone evaluating this repository has to pick a lane before reading further. The topic list on the repository reinforces the breadth: postgres, mongodb, bigquery, sql-server, rest-api, subgraph, supergraph. BigQuery appears in the topics but not in the v3 support sentence, so I cannot confirm from this material whether BigQuery is a v3 connector, a v2 connector, or a leftover tag. That is the kind of gap you should resolve from the Connector Hub rather than from the repository front page.
What the engine actually does: schema introspection in, GraphQL and REST out
The README's own framing is that the engine provides access to data via a single, composable, secure API endpoint. The mechanism implied by that, and by the repository description, is that the engine sits in front of a database, reads its schema, and derives query and mutation fields from it rather than asking you to write resolvers. The description adds two capabilities beyond plain query serving: fine grained access control, and webhooks triggered on database events. Those are the parts that distinguish it from a generic GraphQL gateway. A gateway stitches together schemas you already wrote; this derives the schema from the tables you already have and then applies permission rules to the derived fields. The access-control topic tag and the subgraph and supergraph tags suggest the permission model is expressed at the schema level rather than in application code. The README does not show the permission syntax, does not show an example of a webhook trigger, and does not describe the event delivery guarantees, so treat the webhook feature as advertised rather than characterised. If your evaluation depends on webhook retry semantics or ordering, that has to come from the docs, not from this repository.
Cloning this repository is a decision in itself
The README devotes a whole section to the fact that this is a large and active mono-repo with a long git history, and warns that a first clone can be slow and consume a lot of disk space. It offers two mitigations. The shallow clone is git clone https://github.com/hasura/graphql-engine.git --depth 1, which takes only the latest commit. The narrower option avoids even the working tree: clone with --no-checkout and --depth 1, cd graphql-engine, then git sparse-checkout init --cone, git sparse-checkout set v3, and git checkout @. The README states this checks out the top level files plus only the v3 folder. That sequence is the closest thing in the README to an installation instruction, and it is worth noticing what it is not: it is a source checkout recipe, not a deployment guide. There is no docker run command, no compose file, no environment variable list, no migration or metadata command in the README. If you want a running instance, the README sends you to the DDN quickstart or the v2 docs, which means the repository is the code, and the documentation site is the product experience.
The licence is not one licence, and the split runs along folder boundaries
The README is unusually explicit here, and it matters because the split is easy to get wrong. For v3, the Data Connectors are under Apache-2.0, and the core v3 GraphQL Engine in the v3 folder is intended to be licensed under Apache-2.0. The word intended is the README's, not mine, and it is the kind of hedge worth reading literally. For v2, the core engine is Apache-2.0, but all other contents in the v2 folder are MIT, except for the v2/server, v2/cli and v2/console directories. So docs and community content under v2 are MIT, while the server, CLI and console are not covered by that MIT grant. If you vendor parts of this repository into your own product, the folder you copy from determines the terms. This is a description of what the README says, not legal advice; if the distinction affects a redistribution decision, it needs a lawyer, and it needs a look at the actual licence files rather than the summary paragraph.
Where the README leaves you on your own
Three gaps stand out. First, version selection. The README labels v3 as the future of data delivery and GA, and v2 as the current stable version, which leaves a reader without a clear rule for choosing. If the project considers both production-ready, the deciding factors are data source support and connector model, and the README does not lay those out side by side. Second, self-hosting. The v3 path is described through Hasura DDN and a quickstart link; nothing in the README explains what it takes to run the v3 engine yourself, or whether the DDN architecture assumes a hosted control plane for building and deploying the supergraph. That is a real question for anyone whose data cannot leave their network, and the README does not answer it. Third, the connector model. The README says all Hasura connectors are completely open source and points at the Connector Hub, but the Connector Hub is a separate site, so the repository alone does not tell you which connectors exist today, which are maintained, or what a connector written against the SDK can and cannot express. None of these are disqualifying. They are the parts you must read elsewhere before you can make a decision.
The honest alternative: write the resolvers, or put a gateway in front
The clearest alternative is a code-first GraphQL server such as Apollo Server or GraphQL Yoga, where you define the schema and resolvers yourself. The difference is not performance, it is where the schema lives. With a code-first server, the schema is an artefact you author and version, and each new table means a new resolver, a new type, and a new authorisation check. With Hasura, the schema is derived from the database and the work moves to permission rules and metadata. That trade is favourable when your data model changes often and your access rules are expressible as row and column predicates. It is unfavourable when your GraphQL surface is deliberately narrower than your database, when most fields require bespoke computation, or when you want the schema to be the contract and the database to be an implementation detail. A second alternative is a schema-stitching gateway over existing services, which assumes you already have GraphQL services to stitch; Hasura assumes you have a database and no GraphQL layer. Those are different starting points, and picking the wrong one costs you a rewrite rather than a config change.
Upgrade cost, and what the release cadence implies
The recent releases listed are v2.50.0, v2.50.1 and v2.50.3, dated between early August and early September 2026, with the repository's last push on the same day as the newest release. The patch numbers move quickly within a minor line, which is consistent with an actively maintained v2 branch rather than a frozen one. What the README does not show is a v2 to v3 migration path. The README presents v3 as a different architecture built around Data Connectors and DDN, and the two engines live in separate folders with separate READMEs. Nothing here describes a supported upgrade route, a compatibility layer, or a metadata translation tool. If you are running v2 today, the practical question is not whether v3 exists but whether the DDN deployment model fits your environment, and that question is answered on the docs site or not at all. Budget for the possibility that v2 and v3 are parallel products you choose between, not a sequence you move through.
Editorial conclusion
Adopt Hasura if you need one GraphQL endpoint in front of an existing relational database with row and column level access rules, and you are willing to run a server process next to that database. Do not adopt it if you cannot accept that the README gives no v2 quickstart and no v3 self-hosting instructions, or if you need a data source outside the set the v3 README names. Before committing, clone with --depth 1, run git sparse-checkout set v3 to see how much of the repo you actually need, and read v3/README.md and V2-README.md in full rather than the top level file.
Community notes