gqlith vs the alternatives

Hasura is still the default reach in this space, but the ground has shifted: the company pivoted its headline to PromptQL (June 2025), v2 is on LTS with EOL in January 2027, and DDN’s own feature matrix lists REST as engine-plugin-only, event triggers as work-in-progress and cron triggers as unsupported. There is no native MCP endpoint — the official MCP offering is an alpha shim around the separate PromptQL product. Authorization is Hasura’s own layer, which by its own docs replaces Postgres RLS rather than using it. And while the DDN engine and connectors are Apache-2.0, metadata builds require the proprietary cloud control plane — there is no free, open path to compile metadata on your own infrastructure.

PostGraphile is what we admire most among the runtime libraries, and v5 (GA March 2026, on the Grafast planning engine) is a real step: subscriptions are now built in and free, and `graphile-export` can export the server schema as executable code. Its authorization philosophy is the opposite of Hasura’s — it respects your hand-written Postgres RLS policies via per-request role switching, enforced for any client that touches the database. It never writes those policies, though: RLS remains something you author and maintain by hand. gqlith compiles the same `@gqlith.*` annotations to both app-layer filters and (opt-in) generated `CREATE POLICY` DDL, so the database enforces the model without a second, hand-maintained policy layer. PostGraphile remains GraphQL-only — no REST, no MCP, no typed client — file uploads are an unported v4 community plugin, background jobs and crons come from the first-party Graphile Worker you wire up separately, and it runs as a Node server process.

pg_graphql resolves GraphQL right inside Postgres — small, fast, and as native to the database as it gets. It depends entirely on Postgres RLS for authorization, which is a strength and a constraint. It has no subscriptions, no nested mutations (issue #294), no REST, and no MCP. Its SQL-comment configuration is limited to naming, pagination and aggregate toggles — not RBAC, tenancy, OCC, audit or validation. Worth knowing the platform context too: Supabase has been walking back instant-API defaults (new tables are no longer auto-exposed as of April 2026, and GraphQL-off-by-default is planned), and Supabase’s typegen emits types for a generic query builder rather than a generated SDK. We compare here so the trade-off is visible: pg_graphql is a great fit when everything you need fits its narrow surface.

PostgREST (v14 as of late 2025) is the cleanest standalone REST-from-Postgres option, with a thoughtful filter syntax and a clear authorization model (RLS plus JWT-derived `SET ROLE`). It is REST-only — no GraphQL, no MCP, no subscriptions, no storage — and one request equals one resource transaction, so multi-resource atomic writes are not on the menu. It is deliberately a narrow engine; the layer gqlith generates above it — typed clients, files, webhooks, crons, tenancy, audit — simply isn’t its job.

Exograph is the closest match in shape for what we are building, and we both landed on the same conclusion about agents: let them write GraphQL against a governed endpoint instead of juggling dozens of rigid tools. The differences are in depth and breadth. gqlith’s MCP surface is self-describing and permission-projected — `describe_schema` and `filter_help` hand the agent a guide covering only what the caller may see, with runnable examples, and reads are split from writes at the wire. Exograph’s REST surface has been "coming soon" since 2025; there is no typed client SDK, no storage pipeline, and nested mutations support create/update/delete only. It ships things we don’t have yet — an access-controlled `Vector` type for similarity search and enforced persisted operations. The BSL license also prohibits BaaS-style hosting until Feb 2028.

Cosmo is in a different category — a federation router, not a database-introspection codegen — and we list it for clarity rather than parity. It is genuinely well-equipped at its own layer: safelisted `.graphql` operation files become MCP tools with per-tool JWT scopes from `@requiresScopes`, ConnectRPC turns named operations into HTTP/JSON endpoints with typed SDKs, and GCRA rate limiting ships free in the Apache-2.0 router. The structural difference is where everything comes from: every Cosmo tool, endpoint and SDK is an operation someone hand-curates over APIs that already exist, and data authorization lives in each subgraph. gqlith derives the whole surface — tools, filters, subscription authorization — from the database schema and the caller’s permissions. If you already federate subgraphs, Cosmo is a sensible router and gqlith could be one subgraph behind it.

Prisma + Pothos is the comparison we take most seriously — same category, same philosophy of owning the code. Prisma’s ORM (v7, now Rust-free) matches our nested-write operator depth, and its in-process client is genuinely well-typed — but it is an ORM, not an API: there is no generated HTTP data surface, so every GraphQL operation is hand-exposed through Pothos, and REST or MCP are yours to build. The platform pivot matters too: Pulse (realtime CDC) was discontinued in March 2025 with no shipped successor, the hosted MCP server is admin-grade and Prisma-Postgres-only, and native RLS support has been an open issue since 2022 (the documented pattern is a session-variable workaround). If assembling that stack by hand is what you want, you can absolutely get there; gqlith is what we want when it should be generated.

ZenStack v3 (GA December 2025, MIT, now on its own Kysely-based engine) shares more philosophy with gqlith than anything else here: declare the schema and the access policies once, get the CRUD plumbing and typed frontend hooks generated. The differences are structural. ZenStack is code-first — the ZModel file is the source of truth and the database follows — where gqlith introspects the Postgres schema you already have and keeps config in SQL comments beside the data. ZenStack’s policies are enforced in the ORM/runtime layer only; they are not compiled to Postgres RLS, so a direct database connection sees everything. Its surfaces stop at REST-plus-hooks — a genuine JSON:API 1.1 handler and typed TanStack hooks, but no GraphQL, no MCP, no subscriptions, no file storage — and its typed JSON (preview) covers reads and validated writes without typed filtering or database-level enforcement. If you are starting a green-field TypeScript app and want Prisma-style modeling with policies, ZenStack is a fine choice; gqlith is built for the Postgres you already run and the surfaces an agent-era product needs.