PostgREST 대 Hasura 대 사용자 정의 API

"PostgREST 또는 Hasura 또는 사용자 정의 API"라는 질문에는 더 유용한 질문이 숨겨져 있습니다. 누가 비즈니스 로직을 작성하고, 어떤 도구를 사용하며, 프로덕션에서 이 코드를 사용하는 사람은 누구입니까? 세 가지 아키텍처는 서로 다르게 반응하며, 이러한 차이로 인해 보안, 구현 속도, 장기적 기술 부채 등 모든 것이 구조화됩니다.

세 개의 열 중 어느 것도 더 나은 것은 없습니다. 각 열은 작업을 다른 곳으로 이동시킵니다. PostgREST는 이를 SQL로, Hasura를 구성 및 웹훅으로, 사용자 정의 API를 클래식 애플리케이션 코드로 이동합니다.

PostgREST는 작성할 백엔드 없이 Postgres 스키마를 REST API(필터, 관계 포함, RPC, JWT 기반 RLS)로 변환합니다. 실제 호환성과 대안에 대한 기사에서 이 범위를 자세히 자세히 설명합니다. 이 비교에서 중요한 것은 PostgREST가 중지되는 위치입니다.

PostgREST에는 임의의 비즈니스 로직이라는 개념이 없습니다. 각 규칙은 RPC 함수, 트리거, 제약 조건, RLS 정책 등 SQL로 표현되어야 합니다. 이는 실수가 아니라 허용되는 제약입니다. 다이어그램은 유일한 정보 소스로 남아 있어 애플리케이션 계층과 해당 계층이 제공하는 기반 사이의 드리프트를 제거합니다.

구체적으로, 직접적인 PostgREST 요청에서 제3자 결제 서비스에 전화하거나, 확인 이메일을 보내거나, JavaScript로 점수를 계산하는 것은 불가능합니다. 이 논리는 SQL(pl/pgsql 함수)에 있거나 외부에서 트리거되어야 합니다. 즉, 더 이상 PostgREST가 아닌 외부 서비스에서 수신되는 NOTIFY이벤트를 게시하는 트리거입니다.

Our article on GraphQL layers on Postgres details where the Hasura engine runs and how its permissions differ from the Postgres RLS. Here, the angle is that of business logic: how to plug custom code into a database managed by Hasura, and where.

작업 Hasura는 선택한 언어로 작성한 HTTP 웹후크를 통해 지원되는 사용자 지정 GraphQL 변형 또는 쿼리를 노출합니다. Hasura는 선언된 스키마에 따라 입력의 유효성을 검사하고 웹훅을 호출한 다음 클라이언트에 응답을 반환합니다. 이는 CRUD를 넘어서는 모든 논리(결제 공급자 호출, 복잡한 계산, 다단계 조정)에 대한 관문입니다.

이벤트 트리거는 반대 방향을 따릅니다. 즉, 테이블에 대한 삽입, 업데이트 또는 삭제가 웹후크를 비동기식으로 트리거하고 실패 시 자동으로 다시 시작됩니다. 이는 대부분의 Hasura 통합이 이 코드를 초기 고객 요청에 연결하지 않고 제3자 서비스(청구, 거래 이메일, 검색 엔진)를 동기화하는 데 사용하는 메커니즘입니다.

Hasura는 또한 이미 작성된 GraphQL 쿼리를 일반적인 REST 경로로 노출할 수 있으며, 이름이 지정된 경로와 매개변수(자체 문서의 용어로 RESTified엔드포인트)를 사용합니다. 프런트엔드 팀이 기본 GraphQL 권한 엔진을 포기하지 않고 REST를 사용하는 것을 선호하는 경우 유용합니다.

전용 기사에서 개발된 상황 알림: Hasura는 2025년 6월부터 AI 에이전트용으로 설계된 계층인 PromptQL에 대한 커뮤니케이션에 다시 집중했습니다. GraphQL 엔진을 제거하지 않고 여전히 공식 웹사이트에 "전투 테스트를 거쳤습니다"라고 표시되어 있습니다.

손으로 작성한 API에는 정의상 제한이 없습니다. 모든 비즈니스 로직, 모든 언어, 모든 종속성이 있습니다. 이는 또한 아무것도 생성되지 않는 세 가지 옵션 중 유일한 것입니다. 모든 경로, 모든 검증, 데이터베이스에 대한 모든 연결은 귀하가 소유하고 유지 관리해야 하는 코드입니다.

// 필터, 정렬, 관계 임베딩은 모두 직접 작성하고,
// 이 경로에 대해서만 — 각 API 리소스에 대해 반복합니다.
router.get('/orders', async (req, res) => {
  const { status } = req.query
  const result = await db.query(
    `SELECT o.id, o.total, c.email AS customer_email
     FROM orders o JOIN customers c ON c.id = o.customer_id
     WHERE o.status = $1 ORDER BY o.created_at DESC`,
    [status]
  );
  res.json(result.rows)
});

수동 작업 대신 이 모델이 제공하는 것: 오류 및 반환된 HTTP 코드에 대한 완전한 제어, 고전적인 테스트 가능성(선언적 구성이 아닌 핸들러), 이미 언어를 마스터한 팀이 배울 수 있는 새로운 DSL이 없습니다.

그에 따른 비용: 각 리소스에 대해 직접 작성하고 유지 관리하기 위한 CRUD, 페이지 매김 및 필터; 자동으로 상속된 RLS 없이 직접 구현하고 감사하기 위한 인증 및 권한 부여 각 중첩 관계가 규율 없이 자체 Postgres 쿼리를 트리거하는 경우 N+1 쿼리의 위험; API 문서는 수동으로 유지 관리하거나 타사 생성기를 통해 통합할 수 있습니다.

원시 성능에 관해 "Node.js가 Rust보다 느린가"라는 질문은 그 자체로 하나의 주제입니다. Rust 대 Node.js 대기 시간에 대한 기사에서는 벤치마크 방법론 페이지에 업스트림으로 선언된 방법론과 함께 이를 자세히 다루고 있습니다. 사용자 정의 API는 이미 사용하고 있는 HTTP 서비스와 동일한 성능 프로필을 가지며 구성에 따라 더 좋거나 나쁘지 않습니다. PostgREST가 포화되는 위치와 사용자 정의 레이어가 필요한 지점을 정확히 알려면 프로덕션에서 PostgREST의 실제 한계에 대한 기사를 참조하세요.

아키텍처 외에도 구현 속도, 실제 비즈니스 유연성, 장기 기술 부채, 각 옵션이 가장 적합한 일반적인 사용 사례 등 선택할 때 가장 자주 나타나는 네 가지 기준이 있습니다.

Aurabase Postgres 엔진 프로젝트에서 CRUD 레이어는 대략적인 재구현이 아닌 실제 PostgREST 인스턴스로 이미 처리되어 있습니다. 이 비교를 위해 아직 열려 있는 질문은 CRUD를 넘어서는 내용을 어디에 작성해야 하는가입니다.

두 가지 경로가 존재하며 서로 배타적이지 않습니다. 첫 번째: SQL로 표현하기에 합당한 모든 논리에 대해 RPC에 노출된 SQL 함수 — 전체 계산, 여러 테이블 간의 교차 유효성 검사, 단일 트랜잭션의 계단식 업데이트.

curl -X POST "https://<gateway>/v1/db/<project_id>/rpc/apply_discount" \
  -H "apikey: <votre-cle-api>" \
  -H "Content-Type: application/json" \
  -d '{"order_id": 42, "code": "WELCOME10"}'

두 번째 방법: 결제 API 호출, 이메일 보내기, 임베딩 계산 등 SQL 도메인을 넘어서는 모든 작업을 위한 Edge Functions입니다. Aurabase에는 두 가지 경로가 있습니다. Supabase에서와 똑같이 Deno(TypeScript) 코드를 실행하는 Studio 편집기와 Rust로 작성되고 WASM으로 컴파일된 함수에 대한 별도의 경로를 목표로 하는 aura functions deployCLI입니다. 자세한 내용은 통합 Rust 아키텍처에 설명되어 있습니다. 해당 서버가 전적으로 귀하의 책임인 이 문서의 순수 "사용자 정의 API" 옵션과 달리 두 경로 모두 별도의 노드 서버를 호스팅할 필요가 없습니다.

이 배포판은 여기에 비교된 세 가지 모델 간의 불안정한 절충안이 아닙니다. 말 그대로 CRUD용 PostgREST, RPC 및 트리거를 통한 이벤트 로직용 Hasura Actions에 가까운 벽돌, "모든 PostgREST"와 "모든 사용자 정의" 사이에서 바이너리 선택을 강요하지 않고 완전한 애플리케이션 서버의 작동을 방지하는 Edge Functions입니다.

네 가지 상황이 가장 자주 발생합니다. 올바른 선택은 주로 도구의 인기가 아니라 비즈니스 논리에 필요한 것이 무엇인지에 달려 있습니다.

• 스키마가 안정적이고 비즈니스 논리가 SQL에 있습니다. 자체 호스팅 PostgREST 또는 기본적으로 통합된(Aurabase, Supabase)이면 충분합니다. 더 이상 호스팅할 것이 없으며 스키마는 유일한 정보 소스로 남아 있습니다.
• 여러 데이터 소스를 통합하려고 하거나 로드맵이 데이터를 소비하는 AI 에이전트에 맞춰져 있습니다. PromptQL 레이어를 갖춘 Hasura는 이 지형에 더 잘 맞습니다.
• 귀하의 제품에는 풍부한 비즈니스 논리, 수많은 타사 통합 및 이미 애플리케이션 언어를 갖춘 팀이 있습니다. 사용자 정의 API는 작성하고 시간이 지남에 따라 유지 관리하는 비용이 들지만 여전히 가장 직접적인 선택입니다.
• 비즈니스 로직(RPC, Edge Functions)을 위한 실제 공간을 포기하지 않고, 활용할 애플리케이션 서비스를 하나 더 쌓지 않고 자체 생성 CRUD를 원합니다. 이는 이전 섹션의 Aurabase에 적용된 비교에서 문서화된 각도입니다.