Introducing Constellation: an open-source, Hasura-compatible GraphQL engine | Nhost7KSign inSign up

Back to BlogProduct · GraphQL · Open Source|27 May 2026<br>Product | GraphQL | Open SourceIntroducing Constellation: an open-source, Hasura-compatible GraphQL engine<br>27 May 2026<br>Posted byDavid Barroso<br>CTO

Nuno Pato<br>CEO

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...