---
title: "pg_graphql v1.0"
description: "pg_graphql 1.0 marks the general availability of a PostgreSQL extension that lets databases be queried with GraphQL and formalizes a SemVer-based guarantee against backward-incompatible changes. It was designed for Supabase Free Plan servers with 1 GB of memory, where alternatives such as Hasura and Graphile consumed more memory than the platform could sacrifice. The implementation began with a C parser and SQL transpiler exposed through PostgREST RPC, then moved from SQL to Rust after nested SQL functions, copied state, and JSONB AST processing slowed schema introspection; v0.5.0 completed the rewrite. On Free Plan hardware, version 1.0 adds less than 300 microseconds per request, reaches about 1,060 SQL queries per second per connection, and the full Auth and HTTP stack handles about 645 requests per second, while larger instances exceed 10,000 requests per second."
---

# pg\_graphql v1.0

[Supabase](https://yomu.fyi/company/supabase) · oli\_rice · Dec 16, 2022

**Type:** Announcement

## Summary

pg\_graphql 1.0 marks the general availability of a PostgreSQL extension that lets databases be queried with GraphQL and formalizes a SemVer-based guarantee against backward-incompatible changes. It was designed for Supabase Free Plan servers with 1 GB of memory, where alternatives such as Hasura and Graphile consumed more memory than the platform could sacrifice. The implementation began with a C parser and SQL transpiler exposed through PostgREST RPC, then moved from SQL to Rust after nested SQL functions, copied state, and JSONB AST processing slowed schema introspection; v0.5.0 completed the rewrite. On Free Plan hardware, version 1.0 adds less than 300 microseconds per request, reaches about 1,060 SQL queries per second per connection, and the full Auth and HTTP stack handles about 645 requests per second, while larger instances exceed 10,000 requests per second.

## Context

pg\_graphql was created for Supabase Free Plan projects running on servers with 1 GB of memory. The platform needed GraphQL support while preserving memory for PostgreSQL, indexes, and large queries; surveyed alternatives including Hasura and Graphile supported the desired features but consumed significantly more memory than the Free Plan could sacrifice.

## Approach / What changed

pg\_graphql began as a PostgreSQL extension with a C parser and SQL-based GraphQL-to-SQL transpiler, exposed through PostgREST's RPC functionality. The implementation later adopted Rust through pgx and was rewritten as a pure Rust project for v0.5.0, replacing expensive SQL abstractions and addressing performance problems caused by copied function state, deeply nested calls, and a JSONB GraphQL AST.

## Takeaways

- The extension uses a standard unprivileged SQL function, so PostgreSQL role permissions and Row Level Security policies apply across SQL, REST, Realtime, and GraphQL.
- Embedding GraphQL in PostgreSQL keeps schema inspection synchronized without a separate cache or process and compiles requests into one SQL query, addressing the N+1 query problem.
- On Free Plan hardware, pg\_graphql overhead is below 300 microseconds per request; SQL execution reaches about 1,060 queries per second per connection, while the full Auth and HTTP stack reaches about 645 requests per second.

**Tags:** [Architecture](https://yomu.fyi/topic/architecture), [GraphQL](https://yomu.fyi/topic/graphql), [Performance](https://yomu.fyi/topic/performance), [Postgres](https://yomu.fyi/topic/postgres), [Rust](https://yomu.fyi/topic/rust)

- Source: [Supabase](https://supabase.com/blog/pg-graphql-v1)
- Source URL: https://supabase.com/blog/pg-graphql-v1
- Ingested by Yomu: 2026-08-29T01:15:50.650Z

[Read original post](https://supabase.com/blog/pg-graphql-v1)