pg_graphql 대 Hasura 및 Postgres의 PostGraphile

pg_graphql는 SQL 스키마를 검사하고 Relay 규칙( <table>Collection, edges, node)을 준수하는 GraphQL 스키마를 생성하며 열 유형별 필터, 커서별 페이지 매기기를 생성합니다. 직접 작성하거나 유지 관리할 SDL이 없습니다. GraphQL 스키마는 Postgres 스키마를 따릅니다.

아키텍처에서 중요한 점은 이 스키마 생성기가 옆에 있는 HTTP 프로세스가 아닌 SQL 함수로 데이터베이스 내부에 있다는 것입니다. Aurabase는 Postgres 이미지(Supabase에서 배포한 것과 동일한 공식 .deb 패키지)에 1.6.1 버전의 확장 프로그램(2026년 5월 7일 출시)을 고정합니다. 공유 클러스터와 전용 Postgres 인스턴스 모두에 설치됩니다.

pg_graphql가 오랫동안 기본적으로 활성화되어 있던 Supabase에서 왔다면 이 논리가 익숙할 것입니다. 자세한 비교 및 마이그레이션 가이드는 동일하게 유지되는 나머지 RLS 스키마 및 정책을 다룹니다.

"Postgres의 인스턴트 GraphQL"의 두 역사적 경쟁자 중 어느 것도 사라지지 않았습니다. 그들의 위치는 바뀌었고, 업데이트된 기사는 2년 전의 상황을 인용하기보다는 이를 반영해야 합니다.

Hasura는 2025년 6월 공동 창립자인 Tanmai Gopal의 서명이 있는 "GraphQL에서 PromptQL로: 새로운 장이 시작됩니다"라는 명시적인 제목으로 게시물을 게시했습니다. 메시지: 회사는 AI 에이전트를 위해 설계된 데이터 액세스 계층인 PromptQL에 대한 로드맵에 다시 초점을 맞추고 있습니다. GraphQL 엔진은 제거되지 않았습니다. Hasura의 홈 페이지에는 여전히 "전투 테스트됨"으로 표시되지만 더 이상 우선 순위 메시지가 아닙니다.

PostGraphile는 그 반대를 수행했습니다. 2023년부터 베타 형태로 개발 중인 버전 5는 Grafast라는 새로운 쿼리 계획 엔진과 함께 2026년 3월 24일에 일반 출시되었습니다. 이것은 활력이 부족한 프로젝트가 아닙니다. 마지막 릴리스인 5.1.4는 2026년 8월 5일부터 시작되었습니다. npm 패키지는 2026년 8월 16일부터 22일까지 주에만 119,230건의 다운로드를 기록했습니다(npm 레지스트리, 2026년 8월 23일 참조).

운영 비용, 공격 표면, 대기 시간 등 모든 것을 구조화하는 차이점은 GraphQL 엔진이 실행되는 위치입니다.

솔직히 말해서 PostGraphile은 pgSettings 및 역할 전환을 통해 Postgres에 권한 부여를 위임합니다. 기본 RLS는 pg_graphql에만 국한되지 않습니다. 여전히 다른 점은 이 브리지를 호스팅하고 구성하는 사람이 누구인지입니다. PostGraphile에서는 바로 여러분입니다. Aurabase에서는 이 작업이 이미 완료되었습니다.

활성화는 프로젝트별로 선택 가능하며 Postgres 엔진 프로젝트용으로 예약되어 있습니다. MongoDB 프로젝트는 요청(GRAPHQL_UNSUPPORTED_ENGINE)을 거부합니다. pg_graphql은 다른 엔진에 상응하는 것이 없는 Postgres 확장입니다.

CLI을 통해 또는 관리 계획을 직접 호출하여:

# 멱등성: 이미 활성화된 프로젝트를 불러와도 아무것도 다시 생성되지 않습니다.
aura projects graphql-enable <project_id>

# HTTP에 해당(관리부, JWT 콘솔)
curl -X POST "$AURA_CONTROL_URL/v1/control/projects/$PROJECT_ID/graphql/enable" \
  -H "Authorization: Bearer $CONSOLE_JWT"

서버 측에서 호출은 프로비저너가 단일 트랜잭션에서 실행하는 graphql_enable 작업을 실행합니다. 즉, 확장 설치, 스키마에서 graphql() 함수 생성, 애플리케이션 역할에 대한 GRANT입니다. 단계가 실패하면 모든 것이 취소됩니다. 래퍼는 중간에 설치되지 않으며 graphql_enabled는 완전히 성공한 후에만 true로 이동합니다.

이는 공유 Postgres 클러스터와 프로젝트당 전용 CNPG 인스턴스(두 개의 서로 다른 Postgres 이미지이지만 동일한 확장 메커니즘)에서 작동합니다. 전용 인스턴스에서 확장은 직접 SQL이 아닌 CNPG 연산자의 선언적 매니페스트를 통해 설치됩니다. 이는 최근 수정 사항입니다. 전용 클러스터는 애플리케이션 수퍼유저 액세스 없이 실행되며 pg_graphql에는 CREATE EXTENSION에 대해 정확하게 이 권한이 필요합니다.

Studio에서 동일한 흐름이 Table Configuration(테이블 구성) 탭을 통과합니다. 거기에 있는 버튼은 프로젝트 수준에서 확장 기능을 활성화합니다. 이는 위와 동일한 HTTP 호출로 수렴될 때까지 폴링합니다. 그런 다음 두 번째 컨트롤은 테이블당 @graphql 지시어를 설정하여 편집기를 떠나지 않고도 totalCount 및 GraphQL 컬렉션의 집계 필드를 활성화할지 여부를 지정합니다.

단일 명령 보기: 활성화 → 프로비저닝 작업 스레드(멱등성, 이미 실행 중인 경우 무작동) → DDL 트랜잭션(확장, 래퍼 기능, GRANT) → graphql_enabled 플래그는 완전한 성공 후에만 설정 → /rpc/graphql를 통해 요청 가능.

Aurabase에서 설정한 기능은 SECURITY INVOKER입니다. — Postgres의 기본 동작으로, 향후 리팩터링 시 실수로 변경되지 않도록 설명되어 있습니다. 실제 호출자의 권한(JWT 클레임에 따라aura_anon, aura_authenticated 또는 aura_service_role)으로 실행되므로 RLS 정책은 REST 요청과 동일하게 적용됩니다.

Hasura의 아키텍처는 구성에 따라 다릅니다. 엔진은 각 GraphQL 쿼리를 Hasura에 특정한 권한 규칙에 의해 제한된 SQL 쿼리로 변환합니다. 이러한 규칙은 위임이 아닌 Postgres RLS에 대한 병렬 시스템인 자체 계층의 역할 및 테이블별로 정의됩니다. 액세스 규칙을 감사하는 장소는 한 곳이 아닌 두 곳입니다.

자체 검사({ __schema { ... } })는 각 Aurabase 프로젝트에서 기본적으로 비활성화된 상태로 유지됩니다. 이는 플랫폼의 나머지 부분과 일관된 자세입니다. Apollo Studio 또는 graphql-codegen과 같은 도구에 필요한 경우 COMMENT ON SCHEMA를 통해 스키마로 활성화할 수 있습니다.

graphql_enabled에서 true로 전환되면 게이트웨이에 전용 /graphql 경로가 나타나지 않습니다. 요청은 SDK에서 호출된 Postgres 함수와 마찬가지로 일반 RPC 프록시를 통과합니다.

curl -X POST "$AURA_URL/v1/db/$PROJECT_ID/rpc/graphql" \
  -H "apikey: $AURA_ANON_KEY" -H "Authorization: Bearer $JWT" \
  -H "Content-Type: application/json" \
  -d '{"query":"query { postsCollection(first: 10, filter: { published: { eq: true } }) { edges { node { id title created_at } } } }"}'

응답은 추가 Aurabase 래핑 없이 GraphQL 사양({ data, errors })을 따릅니다. 게이트웨이는 대상 RPC가 graphql임을 감지하고 일반 RPC와 달리 이를 다시 래핑하지 않습니다. 표준 GraphQL 클라이언트(Apollo, urql, graphql-request)는 출력을 있는 그대로 사용합니다.

활성화 시 다이어그램의 @graphql 지시문을 통해 기본적으로 max_rows: 1000 및 inflect_names: true두 가지 설정이 설정됩니다. pg_graphql는 기본적으로 컬렉션당 10,000행으로 제한됩니다. first:가 없으면 큰 테이블이 메모리를 포화시킬 수 있습니다. inflect_names는 SQL 테이블의 원시 snake_case 대신 읽을 수 있는 유형 이름을 제공합니다.

이 블로그의 정신에 따라 숨기기보다는 문서화합니다.

• 기본 GraphQL 구독이 없습니다. pg_graphql은 실시간 subscriptions이 아닌 쿼리 및 변형을 다룹니다. 이는 Aurabase 누락이 아니라 확장 자체의 제한 사항입니다. 실시간 Aurabase가 존재하지만 GraphQL 구독 브리지가 아닌 별도의 채널(postgres_changes)을 통해 존재합니다.
• Hasura와 같은 선언적 조치가 없습니다. "GraphQL 변이에 연결된 비즈니스 웹후크" 모델은 직접적으로 동등한 것이 없습니다. Aurabase에서 이 로직은 전용 GraphQL 구성을 통하지 않고 Postgres 기능 또는 Edge 기능을 통과합니다.
• Postgres 엔진용으로 예약되어 있습니다. MongoDB 프로젝트는 이를 활성화할 수 없습니다. 해결 방법은 없습니다.

세 가지 옵션 모두 타당합니다. 올바른 선택은 이미 가지고 있는 것과 피하려는 것에 따라 달라집니다.

• Aurabase의 pg_graphql — RLS 데이터베이스 및 정책이 이미 Aurabase에 있고 모니터링할 추가 서비스 없이 이를 쿼리하는 두 번째 방법을 원하는 경우.
• Hasura — 단일 GraphQL 스키마 뒤에 여러 데이터 소스(Postgres뿐만 아니라)를 연합하는 경우 또는 PromptQL 및 해당 AI 에이전트 접근 방식이 로드맵에 적합한 경우.
• PostGraphile v5 — 플러그인 시스템을 통해 생성된 스키마를 정밀하게 제어하고 이를 통합할 Node.js 서버를 이미 실행 중인 경우.

전체 쿼리 구문(열 유형별 필터, orderBy정렬, 커서별 페이지 매김, insertInto<Table>Collection 변형)에 대해서는 공식 pg_graphql설명서를 참조하세요. 아래 Aurabase GraphQL 문서에도 전체 주기가 자세히 설명되어 있습니다.