Postgrest 란 무엇인가? 장단점과 특징

Postgrest 

 

PG DB를 REST API 서버로 만들어주는 웹 서버.

그래서 테이블/뷰/함수를 REST 엔드포인트로 자동 매핑해준다.

예시를 들면, SELECT, INSERT, UPDATE, DELETE 같은 SQL 작업을 GET/POST/PATCH/DELETE 같은 HTTP 메서드로 노출하는 API 게이트웨이, 미들웨어 역할을 한다.

자동 생성된 API 사용 예

• GET /tasks → SELECT * FROM tasks;
• POST /tasks → INSERT INTO tasks ...
• PATCH /tasks?id=eq.10 → UPDATE tasks SET ... WHERE id = 10
• DELETE /tasks?id=eq.10 → DELETE FROM tasks WHERE id = 10

무엇을 보고 API를 만들까?

• 테이블 / 뷰
  • 각 테이블·뷰가 하나의 리소스 엔드포인트가 됨
  • 컬럼은 필드로, PK/UK 등은 필터링에 활용
• 함수 (스토어드 프로시저)
  • STABLE/IMMUTABLE 함수 → GET /rpc/func_name
  • VOLATILE 함수 → POST /rpc/func_name
  • 복잡한 비즈니스 로직은 DB 함수로 구현한 뒤, HTTP로 노출 PostgREST 14+1
• Postgres 권한/롤 & RLS
  • DB의 GRANT, Row-Level Security 정책 등을 그대로 사용
  • PostgREST는 단순히 현재 DB 세션의 권한 안에서만 쿼리를 실행

주요 기능

3.1 자동 CRUD + 고급 쿼리

• CRUD 전부 지원
  • GET = 조회 (SELECT)
  • POST = 생성 (INSERT)
  • PATCH = 부분 수정 (UPDATE)
  • DELETE = 삭제 (DELETE) GeeksforGeeks+1
• 쿼리 기능
  • 필터링: ?status=eq.true&priority=gte.3
  • 정렬: ?order=created_at.desc
  • 페이징: ?limit=20&offset=40
  • 컬럼 선택: ?select=id,title,status
  • 조인: ?select=id,title,project(*),assignee(*) 처럼 FK 기반으로 자동 join

보안 / 인증

DB가 권한의 단일 소스

• API 레벨에서 별도 RBAC을 구현하는 대신,
• PostgreSQL 롤, 권한, RLS로만 접근 제어를 수행

JWT 연동 가능

• 클라이언트가 Authorization: Bearer <jwt> 헤더로 JWT 전송
• PostgREST가 이를 검증 후, 토큰에 있는 클레임을 바탕으로 DB 롤/설정 변경 (예: set role app_user; set local "request.jwt.claim.sub" = 'user_id';)

데이터베이스-우선 철학 (Database-first)

• 비즈니스 로직을 **애플리케이션 서버가 아닌 DB(View/Function/RLS)**에 두는 방식
• 장점:
  • 한 곳에서 로직 관리 → 중복 감소
  • PostgreSQL 옵티마이저를 최대한 활용

4.1 장점

1. API 개발 속도
   • DB 스키마만 잘 정의하면 즉시 API 등장
   • 단순 CRUD용 백엔드를 별도로 짤 필요 없음 Undercode Testing+1
2. 일관성 있는 권한 관리
   • DB 권한/Row-Level Security만 신경 쓰면 됨
   • 여러 서비스/백엔드에서 같은 DB를 접근해도 정책은 DB에서 단일 관리 PostgREST 14+1
3. 성능
   • PostgREST는 Haskell + PostgreSQL에 특화되어 고성능
   • ORM 레이어 없이 바로 SQL 실행 → 오버헤드 적음 blog.brightcoding.dev+1
4. 단순 인프라
   • 배포는 거의 “단일 바이너리 + 설정 + PostgreSQL”
   • Docker 이미지도 공식 제공, Kubernetes에 올리기도 쉬움

4.2 단점 / 고려사항

1. DB 중심 설계 강제
   • 복잡한 비즈니스 규칙을 DB 함수/뷰/RLS로 표현해야 함
   • 팀이 DB에 로직 올리는 것에 거부감이 있을 수 있음
2. REST 이상을 원할 때
   • GraphQL, 실시간 Subscriptions 등은 기본 제공 안 함
   • 이런 기능은 별도 솔루션(Hasura, Supabase Realtime 등)과 비교 필요
3. 복잡한 오케스트레이션
   • 여러 외부 서비스 호출, 트랜잭션에 엮이는 복잡한 오케스트레이션은
   • 여전히 별도의 BFF(Backend For Frontend)나 서비스가 더 적합