PostgresをRustで再実装、Postgresの回帰テストを100%通過

(github.com/malisper)

1 ポイント投稿者 GN⁺ 5 시간 전 | 1件のコメント | WhatsAppで共有

pgrustはPostgres 18.3互換を目指すRustによる再実装プロジェクトで、46,000件以上の回帰クエリでPostgresの期待出力と一致
既存のPostgres 18.3データディレクトリから起動できるディスク互換性を備え、実際のPostgresテストを動作基準としている
現時点では本番環境向けの準備はできておらず、性能最適化もまだ行われていない。既存のPostgres拡張や、PL/Python・PL/Perl・PL/Tclなどの手続き言語拡張とは一般に互換性がない
WebAssemblyデモとDockerイメージ malisper/pgrust:v0.1 で試せる。latest は現在同じリリースを指しているが、固定実行イメージは v0.1
ロードマップには、マルチスレッドのPostgres内部構造、組み込み接続プーリング、JSON中心ワークロードの改善、no-vacuumストレージ実験、AI生成SQL向けのランタイムガードレールが含まれる

pgrustの目標と互換性

pgrustはPostgresをRustで再実装するプロジェクト
対象目標はPostgres 18.3で、46,000件以上の回帰クエリでPostgresの期待出力と一致
既存のPostgres 18.3データディレクトリから起動できるディスク互換性を提供
プロジェクトの目標は、Postgresの内部をより変更しやすくすること
- 挙動はPostgres形式のまま維持
- 実際のPostgresテストを基準として使用
- RustとAI支援プログラミングにより、より深いサーバー変更を探る

現在の状態と制限

pgrustはまだ本番環境向けの準備ができていない
まだ性能最適化されていない
既存のPostgres拡張と手続き言語拡張は、一般にはまだ互換性がない
- PL/Python
- PL/Perl
- PL/Tcl
一部の同梱contribモジュールはすでに移植されており、時間とともにより多くの互換性が得られる可能性がある

実行方法

WebAssemblyデモは https://pgrust.com で実行して試せる
Dockerでの実行には malisper/pgrust:v0.1 イメージを使用する
- イメージ内の psql クライアントを使用する
- malisper/pgrust:latest は現在同じリリースを指している
- 固定されたリリースイメージは v0.1

docker run -d --name pgrust -e POSTGRES_PASSWORD=secret malisper/pgrust:v0.1 && until docker exec -e PGPASSWORD=secret pgrust psql -h 127.0.0.1 -U postgres -c '\q' >/dev/null 2>&1; do sleep 1; done && docker exec -it -e PGPASSWORD=secret pgrust psql -h 127.0.0.1 -U postgres; docker rm -f pgrust

ソースからのビルドと実行

macOSでは icu4c、openssl@3、libpq が必要

brew install icu4c openssl@3 libpq

export LIBRARY_PATH="$(brew --prefix openssl@3)/lib:${LIBRARY_PATH:-}"
export PKG_CONFIG_PATH="$(brew --prefix openssl@3)/lib/pkgconfig:$(brew --prefix icu4c)/lib/pkgconfig:${PKG_CONFIG_PATH:-}"
export PATH="$(brew --prefix libpq)/bin:$PATH"

Debian/UbuntuではビルドツールとICU、OpenSSL、LDAP、PAM、Postgres 18クライアントをインストールする

sudo apt-get update
sudo apt-get install -y build-essential pkg-config libicu-dev libssl-dev libldap2-dev libpam0g-dev postgresql-client-18

ビルドはvendoredのPostgres 18.3共有ディレクトリを指定して cargo build で行う

PGRUST_PGSHAREDIR="$PWD/vendor/postgres-18.3/share" \
cargo build --release --locked --bin postgres

データディレクトリはpgrustの --initdb で作成する

target/release/postgres --initdb \
  -D /tmp/pgrust-data \
  -L "$PWD/vendor/postgres-18.3/share" \
  --no-locale \
  --encoding UTF8 \
  -U postgres

実行時はスタック関連設定と同期I/O設定を併用する

ulimit -s 65520

RUST_MIN_STACK=33554432 target/release/postgres \
  -D /tmp/pgrust-data \
  -F \
  -c listen_addresses= \
  -k /tmp \
  -p 5432 \
  -c io_method=sync \
  -c max_stack_depth=60000

回帰テストと検証結果

Postgresの回帰テストは scripts/run-regression で実行する

PGRUST_BIN="$PWD/target/release/postgres" \
scripts/run-regression

テストランナーはpgrust独自の --initdb と、リポジトリに含まれるPostgres 18.3テストファイルを使用する
PATH にPostgres 18の psql クライアントが必要
- 別の場所にある場合は PGRUST_PSQL=/path/to/psql を設定する
検証済みのリリース結果は、pgrustが46,000件以上の回帰クエリでPostgresの期待出力と一致したというもの

ロードマップとプロジェクト履歴

ロードマップには次の項目が含まれる
- マルチスレッドのPostgres内部構造
  - 組み込み接続プーリング
  - JSON中心ワークロード対応の改善
  - 高速なフォークとブランチングワークフロー
  - no-vacuum設計を含むストレージ実験
  - 誤ったクエリとAI生成SQL向けのランタイムガードレール
  - 突然の悪い実行計画への切り替わりの低減
  - 現在のリポジトリには、回帰テストのマイルストーンに到達した、より新しいpgrust実装が含まれる
  - 以前の公開実装は archive/pre-fabled-2026-06-23 に保管されている
  - 関連する背景リンク
  - Original pgrust launch
  - 67% regression update
  - Four Horsemen roadmap
  - ライセンスはAGPL-3.0

1件のコメント

GN⁺ 5 시간 전

Hacker Newsの意見

原作者です。ここに上がるとは思いませんでした。要約すると、LLMでより良いPostgresを作ってみる実験をしてきました。Postgresは30年ものなので、その間にデータベースについて学んだことも多いと考えています。
書き直しに有用な手法のかなり多くは、再設計にも有用です。まだ公開していない新しいpgrustのバージョンは、現在Postgresのリグレッションテストを100%通過しており、Postgresのプロセスごとの接続モデルの代わりに接続ごとのスレッドモデルを実装しています。トランザクション系ワークロードではPostgresより50%速く、分析系ワークロードでは約300倍速いです。
現時点ではclickbenchでClickHouseより2倍遅いですが、ClickHouseより速くできると思っています。質問があれば答えます。
- 接続ごとのスレッドは性能面ではほぼ常に正しい選択ですが、Postgresが接続ごとのプロセスを採用しているおかげで、怪しげな拡張を好きにロードできます。最悪の場合でもデータベース全体ではなく、そのプロセスだけが死にます。拡張でセグメンテーションフォルトが起きても、全体ではなく一部の接続だけが死ぬような落としどころがあるとよいのですが。
- OLTPで50%改善というのは少し疑わしいです。根拠なく決めつけたいわけではなく、私自身もベンチマークの主張はよくしますし、標準ベンチマークを使ったことは分かっていますが、何か引っかかります。
  どこかでMVCCを壊していて、本番には入れられないトレードオフをしている可能性もあります。リグレッションテストに通っているのは見ました。ちなみにfsyncは有効ですか？リグレッションテストは悪いI/Oパターンをうまく捕まえられないと理解しています。それでも面白いプロジェクトに見えます。
- Postgresとデータベース全般についての実際の経歴と専門性が気になります。結局、何をしているのかを正確に分かっているのか、それとも知らない巨大な地雷が隠れているのかを知りたいです。
- 製品リリースというより実験中だったものを、誰かがHNのスポットライトというバスの下に押し込んだように見えます。これがLLMコーディングでどこまで可能かを見る実験なのか、それとも先に作っておいて、LLMが書いたコードのうちどれだけ受け入れられるかを見る実験なのか気になります。
- 分析系ワークロードでPostgresより約300倍速く、ClickHouseより2倍遅いというのは、データを列指向形式で保存しているという意味ですか？それとも行指向と列指向の両方を使っているのでしょうか？
  似ているけれど別の取り組みとして、δxを作っています。通常のPostgresテーブル内に列指向圧縮データを保存するPostgres拡張なので、レプリケーション、障害復旧、pg_dumpなどがそのまま動作します: https://github.com/xataio/deltax
  現在、単一ノードではClickHouseより30〜40%遅いです。clickbenchに追加するPRがちょうど受け入れられたので、ここで比較を見られます: https://benchmark.clickhouse.com/#system=+liH|_etx|gQ|saB&ty...
こういう書き直しはよく理解できません。たいてい一人が主導するので単一障害点になりやすく、非常に短期間で作られるため、プロジェクトを継続的に作っていく規律を身につけたとは見なしにくいです。
中長期的に維持される可能性も低そうです。貢献したい人もトークン費用を払わなければなりません。AIなしでこうしたプロジェクトを維持するのがだんだん難しくなるからです。これを本番に入れたい人がいるでしょうか？あまり筋が通らないと思います。
- 単なる書き直しだけではなく、改善もあります。趣味で似たようなことをやってみましたが、古い設計、とくにPostgreSQL側の人たちが「別のやり方はできない」と言っていた部分を改善できるか見てみたかったのです。実際には別のやり方ができます。
  本番には入れませんが、データベース内部について多くを学びました。LLM時代でも頭を楽しませるために、私たちの本番データベースにもLLMなしでデータベース機能を実装しています。今はFlexible Paxosで苦労しています。たぶん古くて安定していて単純なRaftを使い続けるでしょうが、それでも興味深いです。
- 興味深い概念実証だと見ています。RustでPostgreSQLを書き直すだけでなく、選んだ依存関係、スレッディングモデルの変更、その他のアーキテクチャ変更の可能性をテストしているわけです。
  LLMはプロトタイプをものすごく速く作るのが得意で、動くプロトタイプは多くの推測に決着をつけられます。元のチーム、またはそれに準じる相当な人数が支えておらず、元のコード品質と保守性に追いついた、あるいは上回ったという信頼できる説明がないなら、こうした巨大プロジェクトの書き直し版は使わないと思います。
  一般論として、LLMでライセンスロンダリングをするのは法的にも道義的にも擁護しにくいと思います。ただしこの場合は、より制限の強いライセンスを選んでいる点で異なります。弁護士ではありませんが、PostgreSQLをダウンロードしてs/MIT/AGPL/したうえで配布することは法的に可能だと理解しています。元のMITライセンス版はそのまま存在するので、説得力のある新機能が出るまでは、あえてそのバージョンを好む理由はありません。
- 完全に同じではありませんが、既存の図面一式をもとに3Dモデルを作り直すことは、ゼロから作るよりずっと速く簡単です。すでに多くの意思決定が済んでいるからです。
- Postgres規模のプロジェクトでは、AIなしで維持するのは事実上ほぼ不可能です。記憶が正しければ、Postgresは100万行以上あります。
これをテストする最良の方法は、忙しい本番データベースの前にPgBouncerのようなプロキシを置き、クエリを既存のPostgresとRust版に同時にミラーリングすることだと思います。
そうすれば実際の負荷で出力と性能を比較できます。しばらく動かしたあと、通常のPostgresインスタンスとテーブルを一つずつ比較してもよいでしょう。
こういうコードはどうレビューすべきなのだろう？普通はコミット履歴をざっと見て、人々が何をどう作業したのかを見るが、LLM が1か月足らずで 7101件のコミットを作ると不可能になる
1日分だけ見ても多すぎる [1]。どうせコミット内容も、それほど多くを教えてくれないかもしれない。GitHub でリポジトリの最初のコミットへ簡単に行く方法も気になる。コミット履歴の探索はかなり面倒に感じる
[1] - https://github.com/malisper/pgrust/commits/main/?since=2026-...
- pgrust で malisper と一緒に作業している。こういうプロジェクトでは、各コミットをレビューするよりも、テストとファジングのプロセスをレビューする方向へ焦点が移っていく気がする
  Postgres のリグレッション、分離、障害テストよりも、はるかに先まで行く必要がある。関連する danluu の記事: https://danluu.com/ai-coding/
- github cli には、昇順/降順のソートフラグ付きでコミットを問い合わせるコマンドがある: https://cli.github.com/manual/gh_search_commits
  before x date のような構文のドキュメントはここにある: https://docs.github.com/en/search-github/searching-on-github...
  高度な検索ページもあるが、日付フィルタでコミットはサポートしていない: https://github.com/search/advanced
  検索ウィジェットで日付を二分探索することもでき、コミットがある最初の日はここ: https://github.com/malisper/pgrust/commits/main/?since=2026-...
  最初のコミット: https://github.com/malisper/pgrust/commit/22113dc36b02973060...
- 一般論として、プロンプト履歴がなく、LLM の「コンパイル」を直接再実行できないなら、これがオープンソースなのかは曖昧だ。コードは読めるがビルドシステムにはアクセスできない「ソース公開」プロジェクトに近い感じもする
  逆に、コミットメッセージを除けば人間の開発者の内部の思考過程にもアクセスできたことはなかったので、秘密のプロンプトが即ち非公開ソースだと言うのも完全に同じではないかもしれない
- GitHub で最初のコミットに簡単に行くには、github.com/user/repo/commits/?after=last_commit_hash+number_of_commits-2 という構文を使える。最新コミットと最後のコミットのために -1、-1 するという形
  例: https://github.com/malisper/pgrust/commits/?after=3646a73515...
- レビューはしない。リグレッションテスト通過が元のものと完全に互換という意味だと信じるしかない
印象的ではあるが、PostgreSQL ライセンス [0] から AGPL [1] へのライセンス変更だ
AGPL は好きだし、真に自由なオープンソースライセンスの中で最高だと思っているが、互換性があるのか心配だ。元のソースから再実装したなら、元のライセンスが適用されるべきではないか？そう思う。Rust の coretools のように、オープンソースソフトウェアをより制限の強いライセンスで再実装する流れがあった。AGPL を選んだという点ではずっと倫理的に見えるが、そもそも変更しないほうが安全ではなかったのだろうか？
[0] https://www.postgresql.org/about/licence/
[1] https://github.com/malisper/pgrust?tab=AGPL-3.0-1-ov-file
- 制限の方向を逆に理解しているように見える。MIT ライセンスの uutils coreutils は GPL の GNU coreutils より制限が少なく、AGPL は PostgreSQL ライセンスより制限が強い
  再実装版をより制限の強いライセンスで配布しても、PostgreSQL ライセンスには違反しない。MIT 系ライセンスが GPL や AGPL より制限が少ない理由は、まさにより制限の強い再ライセンスを認めているからだ
- ライセンスが気に入らないなら、LLM に数日間「移植」させてから、好きなライセンスを付ければいい。最近はどうやらそういうことらしい
- PostgreSQL ライセンスは BSD ライセンスの変種なので、(A)GPL と互換だ
  こう理解すればいい。空の (A)GPL プロジェクトを作り、アップストリームの BSD コードベースを取り込む。元のアップストリームファイルは元の許容的ライセンスの下に残るが、プロジェクト全体はアップストリームライセンスの著作権表示要件を含めて (A)GPL の支配を受ける。GPL はそのような要件を許容している。その後、自分のコードを AGPL として追加し、結合著作物を AGPL で配布できる
  誰かがあなたのコードのうち、あなたが書いた部分だけを持っていくなら、AGPL だけに従えばよい。しかしアップストリームのソースまで含めるなら、アップストリームライセンスの著作権表示要件も引き続き満たす必要がある
- Postgres ライセンスはすでに AGPL と完全に互換性がある。BSD/MIT のほうがより許容的だ
unsafe { が2664個、unsafe fn が1835個ある。これはまったく安全ではない。実際に何が起きているのか、Rustの利点を活かすにはアーキテクチャをどう再設計すべきかを理解したうえでの書き直しには見えない
むしろ、生ポインタを広範に使うAI生成の変換のように見える
- unsafe の大半は、Postgresのパーサに c2rust をかけて生成したパーサの中に閉じ込められている。Postgresのパーサ自体も yacc/bison から生成されるので、慣用的なRustに移すより機械的に移植することにした
  特に深刻だと思う unsafe があれば教えてほしい
- Rustで書くLLMプロジェクトはすべて unsafe=deny に設定している。なぜ皆がこういう反応を予想していないのか分からない
- このレビューコメントをそのままプロンプトにコピーして入れればよさそう。数時間後には「修正済み！」になっていそうだ
書き直しとAIによる書き直しは、はっきり区別すべきだと思う
- 例えばTypeScriptのGoへの書き直しは大半を人間が行い、公開までに1年かかった。人々が信頼できるソフトウェアの書き直しとはそういうものだ
- そこまで単純ではなさそうだ。新しく野心的なプロジェクトのほぼ100%が、ある程度はAIを活用するようになると思う。Zigのように厳格な非AI方針を持つプロジェクトはいくつか知っているが、ごく少数派だと見ている
  では、AIの使用量がどの程度なら「AIによる書き直し」になるのだろうか？
- 書き直しは、LLMのほうが人間より向いている領域のように感じる。大半は単純な反復作業であり、LLMは翻訳作業に向いている。記憶が正しければ、トランスフォーマーアーキテクチャももともとは翻訳のために発明されたはずだ
- メンテナンスのない人間による書き直しは趣味プロジェクトにすぎない。AIによる書き直しは、いったい何のためにトークンを燃やしているのか分からない
- 今や単なるビルドステップになったということだ
こうした書き直しプロジェクトが、テストに依存して動作すると主張している例をよく見る。しかしPostgresやSQLiteのようなソフトウェアを信頼できるものにしているのは、テストそのものというより、運用環境で積み重なった傷跡に近い
信頼性は、何年も運用で回される中で積み上がる
- 膨大なテストスイートの大部分こそが、その運用の傷跡だ。バグやリグレッションが発生するたびに、正しい動作を確認するテストを書くからだ
  SQLiteは良い例だ。SQLiteの膨大な非公開テストは、人々がフォークしにくい要素としてよく挙げられる。Tursoはそれをやってのけたが、同等の誠実さを保証するには会社が必要だ。もちろん何年もの運用も必要になる
- この特定の書き直しへの判断ではないが、テストはソフトウェアが正しく動作することの仕様だ。ある動作が自動テストでカバーされていないなら、特定の変更がその動作を壊さないとは主張できない
  既存の未変更のテストスイートを使って何かが動くと言うのは、完全に合理的だ。プロジェクトが大きいほど、なおさらそうだと思う。運用で得た傷跡はテストスイートに文書化され、保護されるべきで、そうでなければその教訓は失われる
  SQLiteは巨大なテストスイートと広範なファジングで知られている。通常のコードよりテストコードとスクリプトが590倍多い。出典: https://sqlite.org/testing.html
- ならば、その信頼性をアップストリームへ戻しやすくすべきだ
  今このようなLLM変換版でできる最も有用なことは、変換版が元のテストをすべて通るなら、自分のアプリケーションのテストスイートをその上で走らせて、元のテストカバレッジ不足を見つけることだ
  変換版がクラッシュしたり、観測可能な誤動作をしたりするなら、実際のプロジェクトに何らかのリグレッションテストが欠けていたという意味になる。こうした変換プロジェクトを日常的な統合テストマトリックスの1行として安全かつ簡単に実行できれば、アップストリームが将来の更新でうっかり何かを壊すことを、はるかにうまく防げる
- 同意する。バグやリグレッションが発生するたびに正しい動作を確認するテストを書く、という隣のコメントにも同意する
  ただ、こうした書き直しで見えないのは、書き直しによって新たに導入されたバグをどうするのかという点だ。結局、自分たちで現実世界のシナリオにさらされて試練を受ける必要があるのではないか？
- 書き直しを検証する別の方法もある。単にpgrustとpostgresを一緒に実行して出力を比較すればよい
  エッジケースを知っているならそれも走らせればよいし、知らないならファザーや自動化ツールで興味深い入力を探せばよい。不一致を見つけたら、その入力/出力ペアがそのままテストケースになる。そういうツールがあるのかは分からないが、あるならClaudeに渡して開発ループに組み込ませればよい
ブラウザで動くWebAssemblyデモが本当にすっきりしている: https://pgrust.com
なぜこんなに否定的なのか分からない。こういうプロジェクトは学習目的や新しいやり方の探索として興味深いと思う。それの何が問題なのか？
- おそらく理由はこうかもしれない。Postgres + Rust という確立されたブランド名に乗っかっていて、実用性や進展はなく、信頼性にも欠ける
  特にタイトルに Postgres のようなシグナルの強い名前が入り、それを前面に出しているのに、短期・長期の実用性、社会的信頼、ネットワーク効果といった理由から明らかに非実用的だと、反感を買いやすいように思う
- 何十年もの作業がこんなに簡単にコピーされるのを見るのは居心地が悪い
- LLM に書き直しをさせることで、具体的に何を学べるのか気になる
- 人々は、自分の技能や才能が必要だと思っていた仕事を LLM がうまくこなすのを見て、脅威を感じているように思う
  理解はできるが、生産的でもなければ、そこまで合理的でもない否定的感情だ。このスレッドには、これが良いはずがない、良くあってはならない、最終的には破局に終わるに違いないと主張しようとする投稿であふれている。だが、このものが何十年もかけて蓄積された数万件の精巧なテストを通過したという事実は、その反対を示唆している。反論するのは難しい
  もちろん新たな問題が生じる可能性は高いが、それでも印象的な成果だ
- 品質が心配だ。コードをざっと見ただけでも間抜けに見える。コードの天才的な部分を自分が見抜けていないのでなければ
  https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b...
  https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b...

PostgresをRustで再実装、Postgresの回帰テストを100%通過

pgrustの目標と互換性

現在の状態と制限

実行方法

ソースからのビルドと実行

回帰テストと検証結果

ロードマップとプロジェクト履歴

マルチスレッドのPostgres内部構造

関連記事

1件のコメント

Hacker Newsの意見