cloudparts

GraphQL-native databases

Databases, or thin engines over one, that publish a GraphQL API generated from the schema, so clients query tables and relationships without a hand-written API server.

2 technologies on this page ↓

How it works

Normally a GraphQL server is code: you write a schema and a resolver for each field, and the resolvers call the database. A GraphQL-native setup generates both from the database itself. Tables or types become GraphQL types, foreign keys or links become nested fields, and the engine adds filtering, sorting, pagination and mutations. Instead of resolving field by field, the good ones compile a whole request into one SQL query, which avoids the N+1 problem of one query per row. There are three shapes. Engines in front of an existing database introspect it and run as a separate server: Hasura GraphQL Engine, PostGraphile and Microsoft’s Data API builder. Extensions answer GraphQL inside the database: pg_graphql reflects a Postgres schema and exposes one SQL function, graphql.resolve(), which Supabase serves over HTTP. Databases whose own API includes GraphQL: Dgraph builds its storage from a deployed GraphQL schema and serves it at /graphql, Gel (formerly EdgeDB) has a graphql extension, SurrealDB generates a schema after DEFINE CONFIG GRAPHQL AUTO, and Firebase SQL Connect maps a GraphQL schema to Cloud SQL for PostgreSQL tables. Authorization either reuses the database’s own model, such as roles, grants and row-level security in PostGraphile and pg_graphql, or is declared in the engine, as Hasura’s per-role row and column rules over session variables from a JWT. GraphQL here is an API language; it has nothing to do with graph databases, which store nodes and edges.

Think of it as

An order form printed straight from the warehouse inventory. Customers tick what they want, in the shape they want it, and when the stock list changes the form reprints itself; nobody has to design a new form.

Reach for it when

  • CRUD-heavy apps, admin panels and internal tools where the API mostly mirrors the tables
  • Front-end teams want typed, nested reads across relationships in one request, with generated client code
  • Realtime screens: live queries or subscriptions on top of the same schema
  • Access rules can be written per row, in database policies or as role rules in the engine

Think twice when

  • The API should hide the data model, or most of the work is business logic: a hand-written GraphQL or REST service keeps the contract independent of the tables
  • A public API for untrusted clients, unless you add depth and cost limits or allow-lists: generated schemas let callers write expensive queries
  • Heavy analytics over large tables; use a warehouse or a semantic layer
  • You don’t want to depend on a small vendor: several products in this space have been sold, shut down or deprioritised since 2024

A real example

A support team’s admin tool runs on Postgres. Hasura tracks the customers, orders and order_items tables, and a select permission lets the support role read only orders from its own region, using a region claim in the agent’s JWT. The React front end asks for a customer with their last ten orders and line items in one GraphQL query, which Hasura turns into a single SQL statement with the region filter built in.

Technologies

Specific products, and what each does differently.

Also used for graphql-native databases

Products of other kinds that are often used this way, grouped by what they are.

What each provider calls it

AWS
AWS AppSync: a managed GraphQL service whose resolvers read DynamoDB, Aurora and RDS, OpenSearch, Lambda or HTTP sources; it can generate a schema from DynamoDB tables, but other sources need resolvers
Google Cloud
Firebase SQL Connect (formerly Data Connect): a GraphQL schema mapped to Cloud SQL for PostgreSQL, with predefined operations and generated client SDKs
Azure
Data API builder: an open-source (MIT) engine that serves REST and GraphQL over SQL Server and Azure SQL, Cosmos DB, PostgreSQL and MySQL from one JSON configuration file
Open source & others
Hasura GraphQL Engine v2 (Apache 2.0); PostGraphile (MIT); pg_graphql (Apache 2.0, built into Supabase); Dgraph (Apache 2.0, owned by Istari Digital since October 2025); Gel’s graphql extension (Apache 2.0; the company shut down in December 2025); SurrealDB’s built-in GraphQL. Fauna’s GraphQL API ended in February 2024 and its service in May 2025

In code · sql

-- pg_graphql: GraphQL resolved inside Postgres by one SQL function
create extension pg_graphql;
create table book(id int primary key, title text);
insert into book(id, title) values (1, 'book 1');

select graphql.resolve($$
query {
  bookCollection {
    edges { node { id } }
  }
}
$$);
-- {"data": {"bookCollection": {"edges": [{"node": {"id": 1}}]}}, "errors": []}

Often confused with

Web APIsBackend as a service (BaaS)Object-relational mappingRelational databasesGraph databases
Where it came from2015–2026

Facebook published GraphQL in 2015 as a protocol, not a database: every field is backed by a function, and storage is up to you. Writing those functions for every table was repetitive, so tools appeared that generated the schema from Postgres. PostGraphile’s repository dates from April 2016, and Hasura launched its GraphQL Engine in July 2018, offering “instant realtime GraphQL APIs on a Postgres database” out of a feature first built for its Kubernetes platform.

Databases then built GraphQL in. Dgraph serves a GraphQL API generated from a deployed schema, and Fauna offered a GraphQL API next to its own query language. In December 2021 Supabase released pg_graphql, which resolves GraphQL inside Postgres; it chose an extension over Graphile or Hasura because its free-tier machines had 1 GB of memory and no room for another process. Cloud vendors added their own: AWS AppSync, Microsoft’s Data API builder and Firebase Data Connect, since renamed SQL Connect.

The independent vendors had a rough few years. Fauna ended its GraphQL API on 29 February 2024 and switched off its service on 30 May 2025. Hasura moved its focus from GraphQL to PromptQL in June 2025 while keeping its engines maintained. Hypermode sold Dgraph to Istari Digital in October 2025, and Gel Data shut down in December 2025, leaving Gel as open source with no company behind it. PostGraphile kept going and released version 5, built on its Grafast planner, in 2026.

Why it’s built this way

Generate the API from the schema
Tables, keys and functions already describe the data, so generating types and resolvers from them removes most hand-written API code and keeps the API in step with migrations.
One SQL query per GraphQL request
Resolving each field separately sends many small queries. Compiling the whole request, with permissions, into one statement lets the database plan it once; pg_graphql returns the result as JSON from that one statement.
Reuse the database’s security or declare it in the engine
PostGraphile and pg_graphql rely on Postgres roles, grants and row-level security, so the same rules protect SQL and GraphQL. Hasura declares per-role rules in its own metadata and writes them into the SQL it generates.
Run inside the database
pg_graphql avoids a separate server process, which mattered on Supabase’s small free-tier machines and removes a network hop.

Timeline

  1. 2015

    Facebook publishes GraphQL

  2. 2016

    PostGraphile’s repository starts in April

  3. 2018

    Hasura GraphQL Engine launches for Postgres

  4. 2021

    Supabase releases pg_graphql in December

  5. 2024

    Fauna ends its GraphQL API on 29 February

  6. 2025

    Fauna shuts down; Hasura shifts to PromptQL; Dgraph sold; Gel Data closes

  7. 2026

    PostGraphile 5 released

Sources15

Improve this page on GitHub