GitHub가 생성한 pgrust 저장소 소개 이미지. 저장소 설명의 100% 회귀 테스트 통과 문구는 README상 미공개 차기 버전을 가리킨다.
3줄 요약
pgrust는 PostgreSQL 18.3의 SQL 동작과 디스크 형식을 유지하면서 서버 내부를 Rust로 다시 만드는 프로젝트다. 공개 저장소는 4만6천 건이 넘는 PostgreSQL 회귀 질의에서 예상 출력과 같은 결과를 냈다고 밝힌다.- 핵심 전략은 새 데이터베이스의 정답을 새로 정의하지 않는 것이다. PostgreSQL 18.3의 회귀 SQL과 예상 출력을 저장소에 함께 두고, pgrust 자체
initdb와 서버가 그 정답을 그대로 재현하는지 검사한다. - README가 덧붙인 회귀 테스트 100% 통과, 연결당 스레드 구조, 트랜잭션 50% 향상, 분석 워크로드 약 300배 향상은 아직 공개되지 않은 차기 버전의 주장이다. 현재 저장소만으로는 코드와 벤치마크를 검증할 수 없다.
무엇을 다시 쓰는가
pgrust의 목표는 PostgreSQL과 비슷한 문법을 지원하는 새 데이터베이스를 만드는 데 그치지 않는다. PostgreSQL 18.3의 동작과 파일 형식을 유지하여 기존 데이터 디렉터리에서 부팅할 수 있는 대체 서버를 지향한다.
공개 저장소가 밝힌 현재 범위는 다음과 같다.
| 항목 | 공개판 상태 |
|---|---|
| 대상 버전 | PostgreSQL 18.3 |
| 질의 호환성 | 4만6천 건이 넘는 회귀 질의에서 예상 출력과 일치한다고 밝힘 |
| 디스크 호환성 | 기존 PostgreSQL 18.3 데이터 디렉터리에서 부팅 가능하다고 밝힘 |
| 초기화 | pgrust 자체 --initdb 구현 포함 |
| 배포 형태 | 소스 빌드, Docker 이미지, WebAssembly 브라우저 데모 |
| 확장 | 일부 번들 contrib 모듈 포팅. 일반 PostgreSQL 확장과 PL/Python·PL/Perl·PL/Tcl은 아직 호환되지 않음 |
| 준비 수준 | 프로덕션 사용 불가, 성능 최적화 전 단계 |
| 라이선스 | AGPL-3.0 |
저장소에는 hstore, ltree, pg_trgm, pg_stat_statements, pgcrypto, amcheck, pg_prewarm, uuid-ossp 등 13개 contrib 모듈 디렉터리가 들어 있다. PL/pgSQL, libpq, WAL, 복제, 플래너, 실행기, 인덱스 접근 방식 같은 PostgreSQL의 넓은 표면도 Rust 크레이트로 분해되어 있다.
2026년 7월 11일 공개 트리를 단순 집계하면 Rust 파일 3,525개, 약 116만 줄, Cargo.toml 1,466개다. 생성 코드와 변환 지원 코드가 포함된 거친 규모 지표이므로 사람이 직접 설계한 코드량으로 읽어서는 안 된다. 다만 PostgreSQL의 세부 단위를 매우 작은 크레이트와 경계 모듈로 쪼갠 저장소의 성격은 잘 드러낸다.
PostgreSQL 자체를 정답지로 쓴다
이 프로젝트에서 가장 중요한 파일은 새 기능의 데모보다 scripts/run-regression이다. 이 스크립트는 저장소에 포함된 PostgreSQL 18.3의 회귀 SQL, 예상 출력, 실행 순서를 사용한다.
검증 흐름은 이렇다.
- pgrust의
--initdb로 새 데이터 디렉터리를 만든다. - pgrust 서버를 실행한다.
- PostgreSQL 18의
psql클라이언트로 원본 회귀 SQL을 차례대로 보낸다. - 실제 출력과 PostgreSQL의 예상 출력 파일을 비교한다.
- 출력 차이, 클라이언트 실패, 서버 크래시를 각각 따로 기록한다.
외부 PostgreSQL 서버나 C로 빌드한 initdb는 필요하지 않다. 실행에 남은 외부 의존성은 PostgreSQL 18 psql 클라이언트다. 즉 공개 저장소를 받은 사람이 pgrust 바이너리와 함께 제공된 정답지로 호환성 주장을 다시 시험할 수 있게 구성했다.
이 방식이 보장하는 것은 어디까지나 테스트가 관찰한 행동이다. 같은 SQL이 같은 출력을 냈다는 사실은 중요하지만, 장시간 부하에서의 내구성, 드문 동시성 경로, 장애 복구, 확장 생태계까지 자동으로 보장하지는 않는다. 저자도 이를 분명히 구분한다.
Compatibility means “this query returns the right answer.” Production-readiness means “this query returns the right answer for the next 90 days under load.”
왜 PostgreSQL을 그대로 고치지 않는가
프로젝트를 시작한 Michael Malis는 PostgreSQL의 약점으로 350개가 넘는 설정, 연결 폭주를 막기 위한 별도 풀러, vacuum이 만드는 운영 위험, JSONB 통계의 한계를 든다. PostgreSQL이 나쁜 데이터베이스라서가 아니라, 약 40년 동안 축적된 내부 구조를 크게 바꾸기 어렵기 때문에 재구현을 택했다.
README의 로드맵은 이 의도를 그대로 보여준다.
- 프로세스 중심 내부 구조를 멀티스레드 구조로 전환
- 연결 풀링을 서버에 내장
- JSON 중심 워크로드 개선
- 데이터베이스 포크와 브랜치 작업 단축
- vacuum이 필요 없는 저장 방식 실험
- 나쁜 질의와 AI 생성 SQL을 막는 런타임 안전장치
- 실행 계획이 갑자기 나빠지는 현상 완화
순서가 중요하다. 먼저 PostgreSQL처럼 행동하게 만든 뒤, 테스트 정답지는 유지한 채 내부 구조를 바꾸겠다는 계획이다. 호환성을 포기하고 자유롭게 새로 만드는 것보다 훨씬 느린 길이지만, 기존 PostgreSQL 생태계와 데이터에 접근할 수 있다는 이점이 생긴다.
AI가 만든 속도와 그 대가
초기 개발 기록은 2026년 4월 20일 공개됐다. 저자는 2주 동안 Codex를 중심으로 개발하여 Rust 코드 25만 줄과 PostgreSQL 회귀 질의 약 3분의 1 통과에 도달했다고 썼다. 첫날에는 3시간 남짓 만에 기본 SQL을 실행했고, 이후 최대 17개 코딩 에이전트를 동시에 운용했다.
일주일 뒤 업데이트에서는 코드가 45만 줄을 넘었고 회귀 질의 통과율이 약 67%가 됐다고 밝혔다. 8개의 Codex 계정으로 10개에서 20개의 세션을 병렬 실행했고, 2주 동안 PR 280개를 머지했다. 처음에는 기능 단위 병렬 작업이 공용 파서·플래너·실행기를 함께 건드려 충돌을 키웠다. 이후 작업을 테스트 하나를 통과시키는 작은 조각으로 줄이고, 공용 빌드 산출물과 머지 큐를 도입하면서 속도가 다시 올라갔다.
이 기록은 AI가 복잡한 시스템을 단번에 이해했다는 증거라기보다, 명확한 정답지와 작은 실패 단위가 있을 때 대량의 에이전트 작업을 공장처럼 운영할 수 있다는 사례에 가깝다. PostgreSQL 회귀 테스트가 없었다면 같은 속도로 늘어난 코드량은 호환성 진척을 말해 주지 못했을 것이다.
Rust를 썼다고 해서 메모리 안전성이 자동으로 완성되는 것도 아니다. PostgreSQL의 ABI, 원시 포인터, 공유 메모리, 신호 처리와 맞닿는 경계에는 여전히 unsafe 코드와 C 스타일 표현이 넓게 남아 있다. 재작성의 현재 가치는 이미 안전하다는 결론보다, 위험한 경계를 Rust 모듈과 명시적 인터페이스로 옮겨가며 고칠 수 있는 토대를 만든 데 있다.
공개판과 미공개판을 구분해야 한다
GitHub 저장소의 설명은 “Postgres rewritten in Rust, now passing 100% of the Postgres regression tests”라고 적혀 있다. 그러나 같은 저장소의 README는 이 성과를 아직 공개되지 않은 새 버전의 업데이트로 분리한다.
README가 미공개판에 대해 주장하는 수치는 다음과 같다.
- PostgreSQL 회귀 테스트 100% 통과
- 연결마다 프로세스를 두는 대신 연결마다 스레드를 두는 구조
- 트랜잭션 워크로드에서 PostgreSQL보다 50% 빠름
- 분석 워크로드에서 PostgreSQL보다 약 300배 빠름
- ClickBench에서 ClickHouse보다 2배 느림
인상적인 수치지만, 현재 공개 코드에는 해당 새 버전과 재현 가능한 벤치마크가 없다. 따라서 지금 확인 가능한 이정표는 공개 저장소가 제시한 4만6천 건 이상의 회귀 질의 출력 일치다. 100% 호환성과 성능 수치는 차기 코드와 측정 조건이 공개된 뒤에 평가해야 한다.
가장 흥미로운 지점
가장 눈여겨본 것은 Rust도, 116만 줄이라는 규모도 아니다. pgrust는 재작성 프로젝트의 순서를 뒤집지 않았다. 새 아키텍처의 장점을 먼저 내세우기보다, 원본 PostgreSQL의 행동을 테스트로 묶어 둔 다음 내부를 바꾸려 한다.
AI 코딩이 대규모 재구현의 비용을 크게 낮추더라도, 무엇이 정답인지 정하는 비용까지 없애지는 못한다. pgrust가 빠르게 전진할 수 있었던 까닭은 PostgreSQL이 40년 동안 축적한 회귀 테스트가 있었기 때문이다. 이 프로젝트는 “AI가 PostgreSQL을 다시 썼다”는 이야기인 동시에, 거대한 정답지가 있는 분야에서 AI 에이전트가 얼마나 강해지는지를 보여주는 사례다.
아직 데이터베이스를 교체할 단계는 아니다. 그러나 오래된 시스템을 그대로 보존하면서 내부 구조만 갈아엎을 수 있는지 시험하는 공개 실험으로서는 충분히 볼 가치가 있다. 다음 판단 시점은 미공개판의 코드와 벤치마크가 실제로 공개되는 때다.
출처
프로젝트 소유자·초기 개발 기록 저자: Michael Malis (malisper)
- 저장소: https://github.com/malisper/pgrust
- 브라우저 데모: https://pgrust.com
- 초기 개발 기록: https://malisper.me/pgrust-rebuilding-postgres-in-rust-with-ai/
- 67% 호환성 업데이트: https://malisper.me/pgrust-update-at-67-postgres-compatibility-and-accelerating/
- 기준 공개 커밋:
c9aecbd(Jason Seibel 작성, 2026-07-10) - 라이선스: AGPL-3.0
저장소 README와 공개 코드를 2026년 7월 11일에 확인했다. 저장소에는 본문에 따로 인용할 도식이 없어 GitHub가 생성한 저장소 소개 이미지만 사용했다.