Postgres가 Rust로 재작성되었습니다… 그런데 놀랍게도 모든 테스트를 통과했네요
원제 · Postgres was rewritten in Rust… and somehow passed every test
핵심 요약
PGRust는 AI를 활용해 Postgres의 100만 줄 C 코드베이스를 Rust로 재작성하여 기존 프로토콜 호환성을 유지하면서도 연결당 스레드 모델을 통한 대폭적인 성능 향상을 도모하고 있다.
하이라이트
PGRust는 기존 Postgres 18.3의 데이터 디렉토리를 호환하며 46,000개의 공식 회귀 테스트 쿼리를 모두 통과했다.
기존 Postgres의 '연결당 프로세스' 모델을 '연결당 스레드' 모델로 재구조화하여 연결 오버헤드를 줄이고 메모리 공유 효율을 높였다.
개발 버전에서는 트랜잭션 워크로드에서 50%, 분석용 워크로드에서는 기존 대비 300배 향상된 성능을 주장한다.
코딩 에이전트를 활용하여 대규모 데이터베이스 엔진 재작성 시 발생하는 아키텍처 실험 비용을 획기적으로 낮췄다.
현재 릴리스는 프로덕션 환경에 적합하지 않으며, 공개되지 않은 개발 버전의 성능 수치는 독립적인 검증이 필요하다.
타임라인
PGRust 프로젝트의 개요와 호환성
Postgres는 40년간 축적된 100만 줄의 C 코드를 기반으로 하여 연결당 프로세스 생성으로 인한 메모리 오버헤드와 병렬 작업의 한계를 가진다. PGRust는 Postgres의 클라이언트 경험과 디스크 형식을 유지하면서 내부를 Rust로 대체하여 이러한 구조적 한계를 극복하고자 한다. 단순한 확장 프로그램이 아닌 별도의 엔진임에도 불구하고 표준 도구 및 쿼리 플래너와 동일하게 작동한다.
- PGRust는 Postgres의 내부 엔진을 Rust로 완전히 재작성한 독립 구현체이다.
- 기존 Postgres 18.3 데이터 디렉토리를 직접 불러올 수 있으며 표준 PSQL 클라이언트와 완벽하게 연동된다.
- 공식 회귀 테스트 스위트 46,000개를 통과하며 기본적인 데이터베이스 서버로서의 기능을 검증했다.
아키텍처 변화와 기술적 트레이드오프
연결마다 개별 프로세스를 생성하던 방식에서 하나의 프로세스 내에서 스레드가 연결을 처리하는 방식으로 변경되어 메모리 오버헤드가 감소한다. 하지만 기존 모델이 제공하던 프로세스 간 격리는 특정 연결의 실패가 전체 서버로 확산되는 것을 방지했으나, 스레드 모델에서는 이러한 보호막이 약해진다. 이로 인해 불안정한 확장 프로그램이나 메모리 오류가 시스템 전체의 안정성을 저해할 수 있는 상충 관계가 발생한다.
- 기존의 연결당 프로세스 모델을 연결당 스레드 모델로 전환하여 리소스 효율성을 개선했다.
- 스레드 모델은 데이터 공유가 쉬워지지만, 프로세스 격리라는 안전장치가 제거되어 버그가 서버 전체에 영향을 줄 위험이 있다.
- 분산 데이터베이스들과 달리 PGRust는 오리지널 Postgres의 동작 방식을 기술 사양으로 삼고 있다.
AI의 역할과 향후 검증 과제
재작성 과정에 AI 코딩 에이전트가 깊게 관여하면서 과거에는 비용 문제로 시도하기 어려웠던 대규모 구조 실험이 가능해졌다. 비록 성능 수치가 고무적이지만 아직 공개된 벤치마크 코드가 없고 미완성 생태계에 머물러 있어 실제 운영 환경 도입은 권장되지 않는다. 프로젝트의 가치는 결과 수치 자체보다 대규모 코드베이스를 재구조화할 수 있는 새로운 개발 방법론을 증명한 데 있다.
- 코딩 에이전트를 적극 활용하여 대규모 아키텍처 재작성 및 실험 속도를 비약적으로 높였다.
- 트랜잭션 50% 향상 및 분석 300배 빠르다는 수치는 아직 독립적 벤치마크 검증이 필요하다.
- 테스트 통과가 실제 운영 환경에서의 장기적인 신뢰성을 보장하는 것은 아니다.
설명
What happens when PostgreSQL is rebuilt in Rust? In this video, we take a look at pgrust, an experimental Postgres rewrite that passes all 46,066 official PostgreSQL regression queries, works with a standard psql client, and can boot from an existing Postgres 18.3 data directory. How closely does it matches real Postgres behavior? We also look at the proposed thread-per-connection architecture, its potential advantages for concurrency, connection overhead, built-in pooling, analytical workloads, and future storage experiments. 🔗 Relevant Links pgrust repo - https://github.com/malisper/pgrust Test pgrust here - https://pgrust.com/ ❤️ More about us Radically better observability stack: https://betterstack.com/ Written tutorials: https://betterstack.com/community/ Example projects: https://github.com/BetterStackHQ 📱 Socials Twitter: https://twitter.com/betterstackhq Instagram: https://www.instagram.com/betterstackhq/ TikTok: https://www.tiktok.com/@betterstack LinkedIn: https://www.linkedin.com/company/betterstack 📌 Chapters: 0:00 PostgreSQL Was Rebuilt in Rust 0:32 Why Postgres Needs a Modern Rewrite 1:00 What Is pgrust and How Does It Work? 1:40 Testing pgrust With Docker and psql 1:55 Running Real SQL Queries and EXPLAIN 2:38 Postgres Process-per-Connection vs Rust Threads 3:10 Can pgrust Replace PostgreSQL Extensions? 4:23 Rust Thread per Connection 5:00 pgrust Performance Claims: 50% and 300x Faster 5:55 Developer Reactions, Risks and Skepticism 6:55 Production Readiness, AGPL and Compatibility 7:45 Should You Replace PostgreSQL With pgrust?