Postgres를 Rust로 다시 쓴 pgrust, 회귀 테스트 4만6000개 100% 통과

• Postgres를 Rust로 다시 구현하는 pgrust가 꽤 큰 마일스톤을 찍었음

  • 목표 버전은 Postgres 18.3이고, Postgres의 실제 회귀 테스트를 기준점으로 삼고 있음
  • 이번 공개에서 내세운 숫자는 4만6000개 이상의 회귀 쿼리 100% 통과
  • 그러니까 “대충 Postgres 비슷한 SQL 서버”가 아니라, Postgres가 기대하는 출력과 최대한 똑같이 맞추는 쪽으로 가고 있음

• 더 흥미로운 건 디스크 호환성까지 주장한다는 점임

  • pgrust는 기존 Postgres 18.3 데이터 디렉터리에서 부팅할 수 있다고 설명함
  • 데이터베이스 재구현에서 이건 꽤 센 주장임. 쿼리 문법만 흉내 내는 것보다 훨씬 아래 레이어를 맞춰야 하니까
  • 다만 “가능하다”와 “운영에서 믿고 쓴다”는 완전히 다른 얘기라, 여기서 바로 갈아타자는 분위기는 아님

• 프로젝트의 목표는 Postgres의 겉모습을 유지하면서 내부를 더 바꾸기 쉽게 만드는 쪽에 가까움

  • “Postgres-shaped behavior”를 유지하고, 진짜 Postgres 테스트를 오라클처럼 쓰겠다는 방향임
  • 구현 언어로 Rust를 쓰고, AI 보조 프로그래밍도 활용해서 서버 내부의 더 깊은 변경을 탐색한다는 설명이 붙어 있음
  • 요즘 유행하는 “Rust로 다시 쓰면 안전해짐” 정도의 얘기보다, 기존 DBMS의 구조적 한계를 건드려보겠다는 색이 강함

• 로드맵에 올라온 아이디어들은 꽤 공격적임

  • 멀티스레드 Postgres 내부 구조
  • 내장 커넥션 풀링
  • JSON-heavy 워크로드 지원 개선
  • 빠른 fork와 branching 워크플로
  • no-vacuum 스토리지 설계 같은 저장소 실험
  • AI가 만든 SQL이나 나쁜 쿼리를 런타임에서 막는 guardrail
  • 갑자기 나쁜 실행 계획으로 튀는 현상을 줄이는 것

• 그런데 아직 프로덕션용은 아님. 이건 프로젝트 쪽에서도 분명히 선을 그음

  • 성능 최적화가 아직 끝나지 않았다고 밝힘
  • 기존 Postgres 확장과 PL/Python, PL/Perl, PL/Tcl 같은 절차형 언어 확장은 일반적으로 호환되지 않음
  • 일부 bundled contrib 모듈은 이미 포팅됐지만, 확장 생태계 전체를 기대하면 아직 이른 단계임

• 그래도 개발자 입장에서는 직접 만져볼 수 있는 재료가 꽤 있음

  • WebAssembly 데모가 있고, Docker 이미지도 제공됨
  • malisper/pgrust:latest는 현재 같은 릴리스를 가리키지만, 출시 이미지로는 v0.1을 고정해서 쓰는 흐름임
  • Postgres 18 psql 클라이언트가 필요하고, 경로가 다르면 PGRUST_PSQL로 지정할 수 있음

• 이 프로젝트가 재밌는 이유는 “Postgres를 대체할 수 있나?”보다 “Postgres 내부를 어디까지 다시 설계할 수 있나?”에 있음

  • Postgres는 워낙 성숙한 시스템이라, 호환성을 깨면 실험이 쉬워지고 호환성을 지키면 실험이 어려워짐
  • pgrust는 어려운 쪽, 즉 기존 동작을 테스트로 맞춰가면서 내부 실험을 하겠다는 길을 택한 셈임
  • 성공하면 Rust 기반 데이터베이스 구현체 하나가 생기는 데서 끝나지 않고, Postgres 자체의 미래 설계 논의에도 꽤 자극이 될 수 있음

---

기술 맥락

• pgrust가 고른 핵심 전략은 “새 데이터베이스를 만들자”가 아니라 “Postgres처럼 동작하게 만들자”예요. 왜냐하면 데이터베이스에서는 SQL 한 줄의 미묘한 결과 차이도 실제 서비스 버그가 되기 쉬워서, 호환성 없는 재작성은 실무 가치가 확 떨어지거든요.

• 그래서 Postgres 회귀 테스트를 오라클처럼 쓰는 선택이 중요해요. 4만6000개 이상의 쿼리에서 기대 출력과 일치했다는 건, 구현체 내부가 Rust로 바뀌었더라도 바깥에서 보이는 동작은 Postgres에 맞춰가고 있다는 뜻이에요.

• 디스크 호환성도 같은 맥락이에요. 기존 Postgres 18.3 데이터 디렉터리에서 부팅할 수 있다면, 단순 SQL 호환을 넘어서 저장 구조와 메타데이터 해석까지 맞춰야 해요. 이게 되는 순간 마이그레이션 실험의 난이도와 의미가 확 달라져요.

• 반대로 확장 호환성은 아직 큰 빈칸이에요. Postgres를 실무에서 쓰는 팀들은 확장, contrib 모듈, PL/Python 같은 절차형 언어에 기대는 경우가 많거든요. pgrust가 프로덕션용이 아니라고 선을 긋는 이유도 여기서 꽤 설득력이 생겨요.

• no-vacuum 설계나 멀티스레드 내부 구조 같은 아이디어는 Postgres의 오래된 운영 부담을 건드리는 쪽이에요. 이런 실험은 기존 C 코드베이스에서 바로 하기 어렵기 때문에, Rust 재구현을 통해 더 과감한 내부 변경을 탐색하려는 흐름으로 보면 돼요.