PostgREST 호환성: 다루는 내용 및 대안

PostgREST는 스키마에서 직접 기존 PostgreSQL 데이터베이스를 REST API로 변환하는 자율 웹 서버입니다. 작성할 애플리케이션 계층이 없습니다. 테이블, 뷰 및 함수가 경로가 되고 SQL 권한(역할, RLS 정책)이 인증 계층이 됩니다.

구체적으로 PostgREST는 거의 모든 평가에서 나타나는 5가지 기능을 다룹니다.

• 수평 필터링 — 약 30개의 연산자(eq, gt, like, ilike, in, is, cs, ov, fts...)에서 직접 쿼리 문자열.
• 수직 필터링 및 포함 — ?select=는 외래 키(예: customer:customers(email))를 통해 열을 투영하고 관계를 포함합니다.
• RPC — POST /rpc/{fonction}는 끝점이 되는 SQL 함수를 직접 호출합니다.
• JWT에 의해 구동되는 RLS — PostgREST는 수신된 토큰(SET LOCAL ROLE)에 따라 활성 Postgres 역할을 전환하므로 애플리케이션 측에서 중복 인증 논리 없이 정책이 그대로 적용됩니다.
• 자체 생성 OpenAPI — 사양은 수동으로 유지 관리할 파일 없이 노출된 스키마에서 추론됩니다.

curl "https://<gateway>/v1/db/<project_id>/orders \
  ?select=id,total,customer:customers(email) \
  &status=eq.paid \
  &order=created_at.desc" \
  -H "apikey: <votre-cle-api>"

단일 HTTP 요청은 유료 주문을 필터링하고, 외래 키를 통해 고객의 이메일을 삽입하고, 날짜별로 정렬합니다. 단일 경로를 직접 작성할 필요가 없습니다.

RPC는 동일한 논리를 따릅니다. 즉, 데이터베이스에 이미 작성된 SQL 함수는 JSON으로 전달된 인수와 함께 POST 엔드포인트가 됩니다.

curl -X POST "https://<gateway>/v1/db/<project_id>/rpc/monthly_revenue" \
  -H "apikey: <votre-cle-api>" \
  -H "Content-Type: application/json" \
  -d '{"year": 2026, "month": 8}'

Postgres 스키마가 API의 단일 소스인 이 원칙은 PostgREST를 예측 가능하게 만드는 것입니다. 모든 동작 변경은 SQL 마이그레이션을 거치며 실제 스키마에서 파생될 수 있는 별도의 애플리케이션 계층을 거치지 않습니다. 이 프로젝트는 특정 BaaS 제공업체와 독립적으로 GitHub에서 개발된 오픈 소스입니다.

PostgREST는 CRUD 계층을 해결합니다. 애플리케이션 백엔드의 나머지 부분은 해결되지 않습니다. 이를 단독으로 채택한 팀에서는 체계적으로 4가지 단점이 발생합니다.

• 인증 — JWT 발급 또는 통합 사용자 관리가 없습니다. SQL로 빌드하거나 외부 서비스에 위임해야 합니다.
• 파일 저장 — 없음. S3 버킷 또는 이와 동등한 버킷은 별도로 연결되어야 합니다.
• 실시간 — PostgREST는 일회성 HTTP 요청에 응답하며 어떤 이벤트도 푸시하지 않습니다.
• 연결 풀러 — PostgREST 자체는 Postgres에 연결되지만 고급 풀러는 통합하지 않습니다. 규모에 따라 이를 관리하는 것은 그 자체로 운영 결정이 됩니다. 클래식 트랜잭션 모드의 풀러는 PostgREST 스키마 다시 로드 메커니즘과 충돌합니다(Aurabase가 이 손상을 해결하는 방법 아래 참조).

실질적인 결과는 명확하게 설명할 가치가 있습니다. 인증이 없으면 RLS 정책이 익명 고객과 데이터 사이의 유일한 보안 경계가 됩니다. anon 역할에 대해 잘못 작성된 정책은 추가 애플리케이션 계층에 의해 대체되지 않습니다.

Aurabase Postgres 엔진 프로젝트(기본 엔진)에서 게이트웨이는 각 CRUD 요청을 이 프로젝트 전용 PostgREST v12.2.8 인스턴스, 즉 테넌트의 Postgres 클러스터와 함께 배치된 두 개의 복제본으로 직접 라우팅합니다. 이것은 대략적인 호환성이 아닙니다. 이는 동일한 연산자, 동일한 임베딩, 동일한 RPC, JWT에 의해 구동되는 동일한 RLS를 사용하는 PostgREST 업스트림 바이너리 자체입니다.

MongoDB 엔진 프로젝트에서는 이야기가 다릅니다. MongoDB에는 PostgREST와 동등한 기능이 없습니다. 이러한 요청은 내부 Aurabase 서비스로 라우팅됩니다. 이 서비스는 동일한 규칙(동일한 연산자 이름, 포함된 ?select= 구문, Prefer 및 Content-Range 헤더)의 하위 집합을 다시 구현하지만 관계형 엔진이 아닌 문서 엔진에서 다시 구현됩니다. 이 계층에는 고유한 제한 사항이 있습니다. 변형에 의해 반환된 표현에 요청된 임베딩은 자동으로 무시되지 않고 명시적으로 거부되며 SQL 함수에 해당하는 RPC 경로가 없습니다.

기술적 세부 사항은 직관과 대조됩니다. 각 전용 PostgREST 인스턴스는 이 테넌트에 배포된 PgBouncer 풀러를 거치지 않고 기본 Postgres에 직접 연결된 상태로 유지됩니다. 가정된 이유: 트랜잭션 풀링 모드는 LISTEN/NOTIFY에 의존하는 PostgREST 스키마 재로드를 중단합니다. 이는 각 트랜잭션에 대한 연결을 재활용하는 풀과 호환되지 않는 영구 연결입니다.

프로덕션의 또 다른 유용한 세부 사항: 리소스를 절약하기 위해 비활성 프로젝트를 일시 중지할 수 있습니다. 휴면 중인 프로젝트에 대한 첫 번째 요청은 절전 모드를 해제하고 재시도 지연, 즉 전용 PostgREST 인스턴스가 다시 작동하는 데 걸리는 시간인 503을 수신합니다. 이는 숨겨진 사고가 아니라 비용과 콜드 대기 시간 간의 가정된 절충안입니다.

PostgREST의 용도는 분명합니다. Postgres 스키마는 정보의 소스이며 팀은 CRUD 레이어를 직접 작성하는 것을 피하고 싶어합니다. 이 특정 사례 외에도 추가하려는 항목에 따라 전혀 없는 것(베어 자체 호스팅)부터 즉시 사용 가능한 완전한 백엔드까지 여러 가지 대안 제품군이 존재합니다.

아래 표는 각 프로젝트에서 선택한 아키텍처에 대한 가치 판단 없이 각 옵션이 기본적으로 다루는 내용과 명시적으로 사용자에게 달려 있는 내용을 비교합니다.

"자체 호스팅"을 선택할 때 종종 과소평가되는 점: PostgREST 자체는 가볍게 실행되지만 프로덕션 작업(버전 업데이트, 고가용성, 풀러와의 연결, 모니터링)은 전적으로 사용자의 책임입니다. 관리형 플랫폼이 흡수하는 것은 소프트웨어가 아니라 이 작업 작업입니다.

For a detailed comparison between GraphQL approaches — pg_graphql, Hasura and PostGraphile — see our article dedicated to the GraphQL API on Postgres.

네 가지 상황이 가장 자주 발생합니다. 올바른 선택은 주로 귀하가 스스로 조립하고 유지하려는 의지에 달려 있습니다.

• 기존 Postgres 스키마에 대한 REST API만 원할 뿐 다른 것은 없습니다. 자체 호스팅 PostgREST이면 충분합니다. 수행하는 작업을 정확히 수행하며 다른 항목을 설치할 필요가 없습니다.
• 추가 인증, 저장 및 실시간이 필요하며 여러 서비스를 조합할 준비가 되었습니다. Supabase 또는 자체 애플리케이션 스택과 함께 제공되는 PostgREST가 이러한 요구 사항을 충족합니다.
• REST보다 GraphQL을 선호합니다. Hasura 또는 PostGraphile이 이 기반을 다룹니다. PostgREST를 직접 대체하는 것이 아니라 다른 아키텍처 선택입니다.
• 여러 개별 서비스를 함께 연결하지 않고 완전한 Postgres 백엔드를 원합니다. 이것은 통합 Rust 아키텍처 문서, 즉 인증, 저장, 실시간 및 에지 기능으로 기본적으로 둘러싸인 CRUD 레이어에 대한 실제 PostgREST를 문서화하는 각도입니다.