Introducing Constellation: an open-source, Hasura-compatible GraphQL engine

Today we're sharing Constellation, a new open-source GraphQL engine written in Go.

Constellation turns a relational database into a role-based GraphQL API, and it's designed to be a near drop-in replacement for Hasura Community Edition. It reads the same metadata, generates a Hasura-compatible schema, and serves the same query, mutation, and subscription surface, including remote schemas and cross-source relationships.

It's already serving production traffic here at Nhost, using a tiny fraction of the memory our Hasura workloads required. It is also early. This post is also an invitation to try it next to Hasura, compare the two engines, and help us find the edges.

Constellation is available today in the Nhost monorepo on GitHub.

A Hasura-compatible GraphQL engine, written in Go

If you've used Hasura CE, you already know how to use Constellation. Point it at the same metadata and the same database and it produces the same GraphQL API:

• The same metadata format: it reads your existing Hasura metadata, either from a YAML/JSON file on disk or straight from Hasura's hdb_catalog.hdb_metadata table.
• The same generated schema: same types, same relationships, same permission-aware shape per role. We verify this with byte-level schema diffs (more on that below).
• The same request surface: queries, mutations, and subscriptions over the same /v1/graphql endpoint, plus remote schemas and cross-source remote relationships.

Under the hood, Constellation is a fresh Go codebase. PostgreSQL and SQLite are first-class backends today, with small interfaces, and a connector design that lets other databases plug in without touching the query planner.

Why we built it

Hasura v2 has been the backbone of Nhost's GraphQL layer for years, and it's a genuinely great piece of engineering. But things have changed:

• Hasura v2 is winding down in favor of v3, and v3 does not follow the same open-source model. That matters for a platform like ours that is built on, and committed to, open source.
• We wanted a lighter, more predictable footprint. A GraphQL engine shouldn't be the most expensive thing in your stack. Memory in particular is hard to throttle gracefully under load, and it was consistently our heaviest service per project.
• We wanted to own a critical piece of our infrastructure. The API and permissions layer sits at the center of every Nhost application. Owning the engine end to end means we can evolve it deliberately, debug issues at their source, and ship improvements without depending on someone else's roadmap.

Continuing to depend on a deprecated open-source engine, or moving our GraphQL and permissions layer to a closed one, wasn't the right path for us. So we built our own while keeping Hasura compatibility on the GraphQL request path. Where Hasura's behavior is surprising or incorrect, we occasionally and deliberately diverge; every such case is documented in KNOWN_DIFFERENCES.md.

Early production results

We've been running Constellation against real production workloads, side by side with Hasura, on the same database and the same traffic. The short version: slightly faster, at a fraction of the resources, even before the performance-focused work still on the roadmap.

Memory

Serving the same traffic, Constellation's memory usage sits ~90% below Hasura's.

Memory usage, same workload: Hasura (yellow) holds steady around 180 MiB, while Constellation (green) sits near ~15 MiB. CPU (left) is shown for the same period.

Footnote on the left-hand CPU panel: Constellation's CPU (green) looks dramatically lower than Hasura's (yellow), but we're talking millicpus here. In absolute terms both engines are cheap on CPU; the gap is real but small in the grand scheme. Memory is where the meaningful difference is.

Latency

Across the same window, Constellation also serves requests a little faster.

Request latency over the same period: Hasura (blue) regularly spikes toward 60–80 ms, while Constellation (purple) mostly stays under 40 ms.

To make the comparison concrete, here's the per-period delta of Constellation minus Hasura for the same traffic. Anything in the green region (below zero) means Constellation was faster; the occasional red spike above the line marks the moments it wasn't.

Latency delta (Constellation minus Hasura). Most of the line sits in the green, below-zero region, meaning Constellation was faster, with a handful of red spikes where it briefly wasn't.

These are raw production dashboards, not a curated benchmark. That's rather the point. We didn't tune anything special to get here.

Early, and running alongside Hasura

Constellation is alpha. The label reflects feature coverage versus Hasura, not the stability of what's there. The core query/mutation/subscription pipeline is battle-tested and in production, but you should go in with eyes open:

• It runs alongside Hasura today, not instead of it. Constellation consumes metadata but doesn't yet implement Hasura's metadata HTTP API (POST /v1/metadata). So the deployment model right now is: Hasura owns metadata authoring, Constellation owns request serving, both pointed at the same database. Once Constellation can manage metadata on its own, the Hasura half can be dropped.
• What's solid: the PostgreSQL and SQLite connectors, the full GraphQL request path, JWT/admin-secret auth, role-based permissions, remote schemas, and cross-source remote relationships.
• What's missing: essentially everything outside the GraphQL request path: Actions, event/cron triggers, REST endpoints, allowlists, query collections, inherited roles, native queries, computed fields, and the MSSQL/BigQuery/Snowflake backends.

If your app lives mostly in the query/mutation/subscription world, there's a good chance Constellation already does what you need. If you lean heavily on Actions or event triggers, keep those on Hasura for now.

Try it: the easiest way is on Nhost

Because Constellation and Hasura can share the same database and metadata, the lowest-risk way to try it is to flip it on next to your existing Hasura instance and run real traffic through it. On any Nhost project, local or cloud, add this to nhost/nhost.toml:

(Pick the latest tag from Constellation's CHANGELOG.md; we recommend always running the latest.)

With that in place, your project runs both engines side by side:

• https://<subdomain>.hasura.<region>.nhost.run → Hasura (metadata authoring, plus anything Constellation doesn't serve yet)
• https://<subdomain>.graphql.<region>.nhost.run → Constellation

Remove the block and you fall straight back to Hasura. That's the whole appeal: try it, run production traffic against it, compare, and back out at any time with zero migration.

Verify it generates the same schema you expect

Because both endpoints are live at once, you can introspect each and diff the SDL per role. The Nhost CLI does exactly this:

An empty diff means Constellation produced a byte-equivalent schema for that role. A non-empty diff should map to one of the documented entries in KNOWN_DIFFERENCES.md.

(Prefer to run it standalone, with no Nhost project? You can. The repository has full build-and-run instructions.)

Help us harden it

This is a call for help, and every path below is useful:

1. Flip it on on a project and point real traffic at it. The Nhost route above is the fastest way in, and it unlocks everything else on this list.
2. Report schema diffs. If nhost schema diff turns up a divergence that isn't covered in KNOWN_DIFFERENCES.md, open an issue with the diff hunk and a minimal metadata snippet. That's how new issues get documented or fixed.
3. Report runtime bugs and inconsistencies. A query that returns different results, a subscription that misbehaves, or a permission that doesn't line up: under live traffic these are the most valuable reports we can get.
4. Dig into the code. It's open source and we've tried hard to make it approachable. PRs and questions welcome.

Constellation is early, but it's already doing real work for us, and the resource numbers above are why we're betting on it. If you run Hasura today, Constellation is ready for the most useful kind of feedback: real metadata, real schemas, real traffic, and real differences. Try it next to your existing Hasura instance, diff the schema, send traffic through it, and tell us what breaks.

Find Constellation, its README, and the issue tracker in the Nhost monorepo on GitHub.