Postgres Rust 재작성 2026, pgrust 테스트·호환성·운영 리스크 기준

Postgres Rust 재작성 pgrust 호환성 테스트를 검토하는 데이터베이스 운영 장면 — pgrust는 흥미로운 실험이지만 운영 DB 교체 후보로 보려면 회귀 테스트와 확장 호환성을 따로 검증해야 한다.

Postgres Rust 재작성이라는 말만 보면 오래된 C 기반 데이터베이스를 더 안전하고 빠른 Rust 서버로 곧바로 바꿀 수 있을 것처럼 들린다.

pgrust는 그런 기대를 만들 만큼 공격적인 실험이지만, 지금 운영팀이 해야 할 일은 교체가 아니라 격리된 호환성 검증이다.

공식 pgrust 사이트와 GitHub README 기준으로 pgrust는 Postgres 18.3 호환을 목표로 하며 46,066개 회귀 쿼리 통과를 내세운다.

같은 문서가 동시에 프로덕션 준비 상태가 아니며 성능 최적화도 아직 끝나지 않았다고 밝히기 때문에, 이 글은 Postgres Rust 재작성을 도입 판단 관점으로만 다룬다.

핵심 요약

pgrust는 Postgres 동작을 Rust로 가깝게 재현하려는 실험이며 운영 교체판으로 보기는 이르다.
회귀 테스트 100% 통과는 강한 신호지만 확장, 절차 언어, 백업, 장애 복구까지 보장하지 않는다.
Docker 실험은 합성 데이터와 격리 네트워크에서만 진행하고 실제 트래픽을 붙이지 않는다.
검토 기준은 성능 호기심보다 호환성, 라이선스, 보안, 운영 인력, 롤백 가능성이다.

이 글이 필요한 사람

Postgres Rust 재작성 pgrust 소식을 보고 운영 DB 실험 가치를 판단하려는 플랫폼 담당자
PostgreSQL 호환 데이터베이스를 검토하지만 확장과 백업 리스크가 걱정되는 DBA
AI가 만든 대규모 시스템 코드와 회귀 테스트 통과 수치를 어떻게 읽어야 할지 보는 CTO
개발팀에서 Docker로 pgrust를 실행해도 되는지 보안 기준을 정해야 하는 DevOps 담당자
Postgres 병목을 해결하려고 샤딩, 연결 풀링, JSON 워크로드 개선 대안을 비교하는 팀

pgrust를 한 줄로 정리하면

pgrust는 Postgres를 Rust로 다시 만든 실험적 데이터베이스 서버다.

목표는 Postgres처럼 보이고 Postgres 테스트를 기준으로 동작을 맞추면서, 내부 구조를 더 쉽게 바꿀 수 있는 기반을 찾는 것이다.

공식 저장소는 Postgres 18.3을 목표로 하고 기존 Postgres 18.3 데이터 디렉터리에서 부팅할 수 있는 디스크 호환성을 언급한다.

다만 이 문장은 운영 데이터베이스의 모든 주변 시스템이 그대로 움직인다는 뜻이 아니다.

확장, 절차 언어, 백업 도구, 모니터링, 드라이버, 장애 대응은 별도 검증 대상이다.

회귀 테스트 100% 통과를 어떻게 해석해야 하나

PostgreSQL 회귀 테스트는 SQL 동작의 많은 표준 경로를 비교하는 강한 기준이다.

pgrust가 46,066개 회귀 쿼리에서 Postgres 예상 출력과 일치했다는 점은 단순 장난감 클론이 아니라는 신호다.

그러나 운영 시스템의 위험은 테스트 케이스 밖에서 더 자주 터진다.

연결 폭주, VACUUM 지연, 백업 복구, 확장 충돌, 관측성 누락, 장애 중 운영자 판단은 회귀 테스트만으로 끝나지 않는다.

따라서 이 숫자는 실험을 시작할 이유이지, 운영 교체를 승인할 이유가 아니다.

검증 신호	긍정적으로 볼 점	아직 남는 질문	운영 판단
46,066개 회귀 쿼리 통과	SQL 결과 호환성 목표가 명확하다	실제 서비스 쿼리와 확장 조합이 같은지 모른다	합성 테스트와 서비스 쿼리 리플레이가 필요하다
Postgres 18.3 목표	비교 기준 버전이 고정되어 있다	조직의 현재 버전과 차이가 있을 수 있다	현재 운영 버전과 업그레이드 경로를 먼저 정한다
디스크 호환성 언급	데이터 형식 실험 가치가 있다	백업, 복구, 장애 시나리오 검증은 별도다	원본 데이터가 아닌 복제본으로만 실험한다
Rust 기반 내부 변경	스레드 모델과 안전성 실험 여지가 있다	성능 수치가 워크로드별로 다를 수 있다	벤치마크보다 실패 모드부터 기록한다

지금 Docker로 해볼 수 있는 최소 실험

Postgres Rust 재작성을 처음 확인할 때는 로컬 Docker 실험만으로 충분하다.

공식 저장소는 malisper/pgrust:v0.1 이미지를 고정 실행 이미지로 안내한다.

latest 태그는 같은 릴리스를 가리킬 수 있지만, 실험 로그에는 태그와 이미지 digest를 함께 남겨야 한다.

아래 흐름은 기능 검증용이며 운영 데이터나 내부 네트워크 쓰기 경로를 붙이면 안 된다.

# pgrust Docker 실험 흐름
# 공식 저장소 README의 v0.1 이미지를 기준으로 로컬 격리 환경에서만 확인한다.

docker pull malisper/pgrust:v0.1

docker run -d --name pgrust-lab   -e POSTGRES_PASSWORD=secret   -p 55432:5432   malisper/pgrust:v0.1

until docker exec -e PGPASSWORD=secret pgrust-lab   psql -h 127.0.0.1 -U postgres -c '\q' >/dev/null 2>&1; do
  sleep 1
done

docker exec -e PGPASSWORD=secret pgrust-lab   psql -h 127.0.0.1 -U postgres   -c "select version(), 1 + 1 as two;"

docker rm -f pgrust-lab

이 단계에서 통과해야 할 결과는 서버가 뜨고 psql이 연결되며 아주 단순한 SQL이 기대한 값을 돌려주는 정도다.

여기서 실패하면 성능 비교나 마이그레이션 검토로 넘어가지 않고 실험을 종료하는 편이 낫다.

운영 DB 교체 후보로 보기 전에 막아야 할 오해

가장 흔한 오해는 Rust로 재작성됐으니 기존 Postgres보다 자동으로 안전하다는 판단이다.

Rust는 메모리 안전성에 강점을 주지만 데이터베이스 운영은 쿼리 플래너, 스토리지, WAL, 복구, 권한, 확장 생태계가 함께 맞아야 한다.

두 번째 오해는 회귀 테스트 통과가 확장 호환성을 의미한다는 판단이다.

pgrust README는 PL/Python, PL/Perl, PL/Tcl 같은 절차 언어 확장이 일반적으로 아직 호환되지 않는다고 밝힌다.

세 번째 오해는 성능 로드맵이 지금 당장 비용 절감을 보장한다는 판단이다.

프로덕션 준비 전 단계에서는 벤치마크보다 장애 발생 시 멈출 기준과 복구 경로가 더 중요하다.

비용·보안·운영 판단표

축	검토 질문	통과 기준	실패하면 생기는 비용
비용	실험 인프라와 DBA 시간이 어느 정도 필요한가	격리 랩에서 하루 단위로 중단 가능한 실험	장기 PoC가 본업 운영 시간을 잠식한다
보안	운영 데이터나 고객 데이터가 실험 환경으로 들어가는가	합성 데이터 또는 익명화 복제본만 사용	데이터 반출과 접근권한 감사 비용이 커진다
호환성	필수 확장과 절차 언어가 모두 확인됐는가	서비스별 extension inventory가 통과	마이그레이션 후 기능 장애가 생긴다
운영	백업, 복구, 모니터링, 알림이 재현되는가	복구 리허설과 관측성 대시보드가 존재	장애 때 원인 파악 시간이 길어진다
라이선스	AGPL-3.0 조건을 서비스 구조에서 검토했는가	법무 또는 오픈소스 정책 검토 기록이 있음	배포와 소스 제공 의무 판단이 뒤늦게 터진다

이 표에서 하나라도 비어 있으면 pgrust 검토는 기술 호기심 단계로 남기는 편이 안전하다.

특히 라이선스와 데이터 반출 기준은 성능 테스트보다 먼저 정해야 한다.

확장과 절차 언어 호환성은 별도 목록으로 본다

운영 Postgres는 순수 SQL만으로 굴러가지 않는 경우가 많다.

pg_stat_statements, PostGIS, pgcrypto, TimescaleDB, 외부 FDW, 커스텀 C 확장, PL/Python 함수가 서비스 어딘가에 숨어 있을 수 있다.

pgrust가 일부 contrib 모듈을 포팅했더라도 조직의 필수 확장이 모두 맞는지는 다른 문제다.

가장 먼저 해야 할 일은 운영 클러스터의 확장 목록과 언어 목록을 뽑아 required, optional, legacy로 나누는 것이다.

required 확장이 하나라도 미검증이면 운영 트래픽 연결은 보류한다.
optional 확장은 대체 경로가 있는지 애플리케이션 담당자가 확인한다.
legacy 확장은 제거 계획과 실험 영향 범위를 따로 기록한다.
확장 ABI와 내부 hook 의존이 있으면 Rust 재작성 서버에서 특히 보수적으로 본다.

백업과 복구 리허설 없이는 마이그레이션이 아니다

데이터베이스 실험에서 가장 위험한 순간은 벤치마크가 잘 나온 직후다.

팀이 흥분해서 실제 데이터를 붙이기 시작하면 백업, PITR, 권한, 모니터링 검증이 뒤로 밀린다.

Postgres 운영 경험이 있는 팀이라면 pg_dump, base backup, WAL 보관, point-in-time recovery, replica 재구성을 실험표에 넣어야 한다.

pgrust 실험은 운영 백업 도구가 그대로 통과한다고 가정하지 말고 복원된 데이터에서 쿼리 결과까지 비교해야 한다.

복구 리허설이 실패하면 성능 결과가 좋아도 운영 후보에서 제외하는 것이 맞다.

실무 시나리오 1: 스타트업이 Postgres 병목을 겪는 경우

작은 플랫폼팀이 연결 수 폭주와 VACUUM 지연으로 장애를 겪고 있다고 가정하자.

이 경우 Postgres Rust 재작성 소식은 매력적이지만, 첫 처방은 pgrust가 아니라 PgBouncer, 인덱스, autovacuum 설정, 쿼리 계획 관측성이다.

pgrust 실험은 장애 원인을 더 잘 이해하기 위한 별도 랩으로 두고, 운영 안정화는 기존 Postgres 도구로 먼저 처리한다.

이 조건이면 pgrust는 기술 레이더에 올리되 분기별 재평가 항목으로만 남긴다.

실무 시나리오 2: 데이터 플랫폼팀이 AI 생성 SQL 가드레일을 검토하는 경우

데이터 플랫폼팀이 사내 분석 도구에 AI 생성 SQL을 붙이려는 상황에서는 pgrust 로드맵의 런타임 가드레일이 흥미롭다.

다만 로드맵은 지금 운영 기능이 아니라 방향성이므로, 팀은 먼저 현재 Postgres에서 statement timeout, read-only role, query allowlist, 비용 제한을 구현해야 한다.

pgrust는 AI 생성 SQL이 나쁜 실행 계획을 만들 때 어떤 방어가 가능한지 연구하는 샌드박스로만 다룬다.

이 조건이면 운영 도입보다 정책 실험과 실패 재현 케이스 수집이 먼저다.

실험 승인 게이트와 점검 스크립트

아래 YAML은 pgrust 실험을 시작하기 전에 승인 범위와 중단 조건을 고정하는 예시다.

# pgrust-pilot-gate.yaml
# 목적: Postgres Rust 재작성 계열 프로젝트를 운영 DB 교체 후보가 아니라 실험 후보로 검증한다.
# 실제 환경명, 데이터 등급, 승인자는 조직 정책에 맞게 수정한다.

owner:
  service: database-platform
  reviewers:
    - dba
    - application-owner
    - security-engineer

allowed_scope:
  environment: isolated-lab-only
  data_classification: synthetic-or-anonymized
  network_access: no-public-write-path
  production_traffic: false

source_baseline:
  upstream_project: pgrust
  target_postgres_version: "18.3"
  pinned_container: "malisper/pgrust:v0.1"
  required_checks:
    - record_repository_commit
    - record_container_digest
    - run_basic_sql_smoke_test
    - run_selected_regression_subset
    - compare_extension_inventory
    - compare_backup_restore_path

stop_conditions:
  - extension_required_by_service_is_missing
  - procedural_language_required_by_service_is_missing
  - backup_or_restore_cannot_be_rehearsed
  - query_result_diff_is_unexplained
  - license_review_is_not_complete
  - latency_or_error_rate_is_unstable

아래 Python 스켈레톤은 필수 기능을 blocker, manual gate, watch로 나누는 단순한 출발점이다.

# pgrust_compatibility_check.py
# 목적: 운영 Postgres를 바꾸기 전 필요한 확장과 기능을 간단히 점검하는 예시다.
# 실제 연결 정보, 인증, 보안 저장소 연동은 조직 기준으로 바꾼다.

from dataclasses import dataclass

@dataclass
class Requirement:
    name: str
    required: bool
    category: str


requirements = [
    Requirement("pg_stat_statements", True, "extension"),
    Requirement("postgis", False, "extension"),
    Requirement("plpython3u", False, "procedural_language"),
    Requirement("logical_replication", True, "replication"),
    Requirement("point_in_time_recovery", True, "backup"),
]

supported_in_lab = {
    "pg_stat_statements": "check_source_build",
    "logical_replication": "needs_manual_test",
    "point_in_time_recovery": "needs_restore_rehearsal",
}


def classify(req: Requirement) -> str:
    status = supported_in_lab.get(req.name, "not_verified")
    if req.required and status in {"not_verified", "unsupported"}:
        return "blocker"
    if req.required and status.startswith("needs_"):
        return "manual_gate"
    if not req.required and status == "not_verified":
        return "watch"
    return "pass"


for item in requirements:
    print(item.name, item.category, classify(item))

실제 환경에서는 이 스크립트를 데이터베이스 접속 코드와 연결하기 전에 비밀 관리, 접근 로그, 실행 권한부터 고정해야 한다.