A PostgreSQL database that answers GraphQL queries itself, with no separate GraphQL server to run, secure or scale.
This product is available in the build below. Open it for the operating system, cloud and version detail, or read its deployment guide.
| Product | Cloud | Operating system | Version | |
|---|---|---|---|---|
| PostgreSQL 18 with pg_graphql on Ubuntu 24.04 LTS | Azure | Ubuntu 24.04 | 18 | View · Guide |
This appliance is a PostgreSQL database with pg_graphql enabled: a GraphQL engine that runs inside the database server. It reflects the tables, columns, primary keys and foreign keys that the connecting account is allowed to see, builds a GraphQL schema from them, and answers queries through an ordinary SQL function call. There is no separate GraphQL process, no extra service to keep running and no additional network port.
That placement is the point. Because resolution happens in the database, a GraphQL query is planned and executed as a single statement rather than as a fan out of round trips, and it is subject to exactly the same grants and the same row level security policies as the equivalent SQL. It suits teams who want a GraphQL surface over relational data without adopting a second server in the path, and teams who want their access rules to live in one place rather than be re-implemented in a middle tier.
The extension is written in Rust and normally has to be compiled. cloudimg installs the official prebuilt release artifact instead, pinned by release tag and verified by checksum, and the licence is re-read and checked at that exact version, so the image carries the extension and no compiler at all. It arrives already enabled in a ready to use database with a small worked example, so a real GraphQL query returns real rows the moment the machine boots. Because the query runs as the connecting account, that example also ships the access model rather than just describing it: the table has row level security enabled and enforced even for its owner, with a policy that returns nothing at all until the session states which tenant it is acting for, so two accounts running the identical query get different results. There is no default password to change and no shared database: every instance initialises its own database cluster on first boot with its own generated passwords and its own TLS certificate, written to a file only the root user can read, and the database listens on loopback until you choose to open it. The paired deployment guide walks through running a query, adding a table of your own and watching the schema pick it up, and every instance carries 24/7 support.