pg_durable 딥다이브
— 크론·큐·워커 없이, Postgres 안에서 끝까지 살아남는 워크플로

1프로젝트 한줄 요약

이 레포가 무엇을 하는 물건인가.

한 줄 맛보기 — 문서 100건을 집어 처리 완료 표시하는 듀러블 함수:

SELECT df.start(
    'SELECT id FROM documents WHERE processed = false LIMIT 100' |=> 'batch'
    ~> 'UPDATE documents SET processed = true WHERE id = ANY($batch)'
);

|=>는 "결과를 batch라는 이름으로 저장", ~>는 "그다음에"라는 뜻의 합성 연산자입니다. 복사해서 돌려보면 인스턴스 ID가 돌아오고, 진행 상황은 df.instances 테이블을 SELECT하면 보입니다 — 모니터링 대시보드도 결국 SQL입니다.

2왜 주목받는가

트렌딩 이유 · 경쟁 대비 장점.

듀러블 실행은 Temporal·Step Functions가 표준으로 만든 패턴이지만, 전부 별도 오케스트레이터 서비스를 요구합니다. pg_durable의 제안은 급진적입니다 — 상태가 이미 Postgres에 있는 팀이라면, 오케스트레이터도 Postgres여야 한다. AI 파이프라인 붐(임베딩 생성→pgvector 적재 같은 행 단위 듀러블 작업 폭증)과 맞물려 06-06 트렌딩 1위에 올랐습니다.

3기술 스택 전체 지도

Rust로 짠 Postgres 확장 — pgrx 생태계의 대형 실례.

4아키텍처 심화 분석

df.start() 한 번이 거치는 길.

구조의 핵심은 오케스트레이션과 액티비티의 분리입니다 — Temporal과 같은 사상인데 무대만 DB 안입니다. 오케스트레이터(그래프 진행 결정)는 결정적이어야 하고, 부수효과 있는 일(SQL 실행·HTTP 호출)은 전부 액티비티로 격리돼 각각 체크포인트를 가집니다. 덕분에 재개 시 "어디까지 했는지"가 모호하지 않습니다. 병렬 fan-out(독립 쿼리 여러 개 동시 실행 후 join)도 그래프 표현으로 자연스럽게 풀립니다.

또 하나 눈여겨볼 것은 src/ssrf.rs — DB 안에서 HTTP를 쏘는 기능은 SSRF (Server-Side Request Forgery, 서버가 내부망으로 요청을 쏘게 속이는 공격)의 통로가 되기 쉬운데, 도메인 허용목록을 컴파일 타임 feature(http-allow-azure-domains 등)로 강제합니다. "편의 기능엔 반드시 보안 가드"의 모범입니다.

5디렉토리 구조 해부

어떤 폴더가 무슨 일을 하나.

6학습 포인트 (기술별)

이 레포에서 배울 만한 것 + 어디를 보면 되는지.

7시스템 요구사항

돌리려면 무엇이 필요한가.

8직접 해볼 수 있는 실습 과제

난이도별로 손에 익히는 단계.

9관련 기술 심화 학습 로드맵

한 주씩 따라가는 계획.

10핵심 키워드 사전

본문에 나온 용어 빠른 참조.

11참고 링크

• GitHub: microsoft/pg_durable
• 공식 사이트: microsoft.github.io/pg_durable
• 아키텍처 문서: docs/ARCHITECTURE.md
• pgrx: pgcentralfoundation/pgrx