ハクソク

世界を動かす技術を、日本語で。

Rustで書き直されたPostgresが、Postgresの回帰テストを100%通過しました

2026年7月9日原文(github.com)

概要

pgrust は、 Postgres 18.3 互換を目指した Rust製の再実装。 4万6千件以上の回帰テスト でPostgresと同一出力を達成。 Postgresのデータディレクトリ から起動可能な ディスク互換性 を保持。 現状は 本番運用・拡張機能対応 が未完、今後の開発が進行中。 WebAssemblyデモやDockerイメージ で簡単に試用可能。

pgrust概要

  • Postgres 18.3 を Rust で再実装したプロジェクト
  • Postgresの出力 と一致するよう 4万6千件超の回帰テスト を通過
  • ディスク互換性 を持ち、既存の Postgres 18.3データディレクトリ から起動可能
  • 目的： Postgresの内部構造の変更容易化、 Rust+AI支援 によるサーバの深部改良
  • 本番環境未対応、 パフォーマンス最適化未実施
  • Postgres拡張機能 （PL/Python, PL/Perl, PL/Tcl等）は未対応
    • 一部の contribモジュール は移植済み、今後対応範囲拡大予定

今後のロードマップ

  • マルチスレッド対応Postgres内部
  • 組み込みコネクションプーリング
  • JSONワークロード最適化
  • 高速なフォーク・分岐ワークフロー
  • バキューム不要なストレージ設計の実験
  • AI生成SQLや悪質クエリのランタイムガードレール
  • 突発的な悪いプラン切替の抑制

試用方法

  • WebAssemblyデモ ： https://pgrust.com
  • Docker利用手順
    • docker run -d --name pgrust -e POSTGRES_PASSWORD=secret malisper/pgrust:v0.1
    • docker exec -it -e PGPASSWORD=secret pgrust psql -h 127.0.0.1 -U postgres
    • 終了: docker rm -f pgrust
  • psqlクライアント はDockerイメージ内蔵
  • malisper/pgrust:latest は v0.1 と同一リリース指向

ソースからのビルド

  • macOS準備
    • brew install icu4c openssl@3 libpq
    • 必要な 環境変数 設定
  • Debian/Ubuntu準備
    • sudo apt-get update
    • sudo apt-get install -y build-essential pkg-config libicu-dev libssl-dev libldap2-dev libpam0g-dev postgresql-client-18
  • ビルドコマンド
    • PGRUST_PGSHAREDIR="$PWD/vendor/postgres-18.3/share" cargo build --release --locked --bin postgres
  • データディレクトリ初期化
    • target/release/postgres --initdb -D /tmp/pgrust-data -L "$PWD/vendor/postgres-18.3/share" --no-locale --encoding UTF8 -U postgres
  • 起動方法
    • 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
  • 接続例
    • psql -h /tmp -p 5432 -U postgres -d postgres -c "select version(), 1 + 1 as two"

回帰テスト

  • Postgres回帰テスト をpgrustで実施可能
    • PGRUST_BIN="$PWD/target/release/postgres" scripts/run-regression
    • Postgres 18のpsqlクライアント がPATH上に必要
    • pgrustの--initdb と Postgres 18.3のテストファイル を利用
  • 4万6千件超の回帰クエリ でPostgresと一致した出力を確認

歴史・背景

  • 現行リポジトリ は新しいpgrust実装
  • 旧実装 はarchive/pre-fabled-2026-06-23にアーカイブ
  • 参考リンク
    • オリジナル発表: https://malisper.me/pgrust-rebuilding-postgres-in-rust-with-ai/
    • 67%互換時点: https://malisper.me/pgrust-update-at-67-postgres-compatibility-and-accelerating/
    • Four Horsemen ロードマップ: https://malisper.me/the-four-horsemen-behind-thousands-of-postgres-outages/

フィードバック・連絡先

  • Issue提出 でバグ・要望・セットアップの質問を受付
  • 連絡方法
    • Email: maintainers@pgrust.com
    • Discord: https://discord.gg/FZZ4dbdvwU
    • メーリングリスト: https://malisper.me/subscribe/

ライセンス

  • AGPL-3.0 でライセンス提供
  • 詳細は LICENSE ファイル参照

Hackerたちの意見

リライトとAIリライトの違いをしっかり分ける必要がある気がする。

└

同意だけど、Bunから学んだのは、すごく良いテストと十分なトークンがあれば、プロジェクトは他の言語にかなりうまく移行できるってことだよね！

└

その二つの間に測れる品質の違いはあるの？それとも「雰囲気」で判断してるの？同じ開発者が書いた手動のコードとAI生成のコードの品質に相関関係はあるのかな？こういう粗い意見は無駄な摩擦を生むだけだよ。もしコードを出力するブラックボックスがあって、トップレベルの開発者とそのブラックボックス内のAIの品質を区別できないなら、その区別は必要ないよ。ネット上のほとんどのコードは、すでに君にとってはブラックボックスなんだから。君のマシンで動いているコードのうち、誰が書いたかやコードの品質を確認したのはどれくらいある？AIによるコーディングは消えないし、今後はほとんどのコードを生成することになるだろうから、完全に拒否したり恣意的に分類するのではなく、誰が書いたかに関わらず、コードと機能のしっかりした定量的・定性的な評価に焦点を当てる必要があるよ。

└

そんなに単純じゃないと思う。新しい野心的なプロジェクトのほぼ100%は、少なからずAIを活用することになるだろうね。厳格なノーAIポリシーを持ってるプロジェクトもいくつか知ってるけど（例えばZig）、それは少数派だと思う。じゃあ、どれくらいAIを使ったら「AIリライト」になるの？

└

今やただのビルドステップだね。

└

ますます未来になってきてるよ。人間は一つの技術を別の技術に書き換えたがらないから、得られる利益が微小すぎるからね。でもAIはそんなこと気にしない。

└

リライトって、LLM（大規模言語モデル）が人間より得意な分野だと思う。ほとんどが単純作業だし、LLMは翻訳タスクに向いてるからね（確かトランスフォーマーアーキテクチャは元々翻訳のために作られたんだよね）。

└

それは違うよ… プロジェクトのメンテナーによるリライトとフォークの違いなんだ。

└

例えば、GoでのTypeScriptのリライトはほとんど人間によって行われて、リリースまでに1年かかったよ。これが、人々が信頼できるソフトウェアのリライトの仕方なんだ。

└

AIによるリライトには、すでに確立された用語があるよ。

└

メンテナンスなしの人間のリライトはただの趣味プロジェクトだね。AIのリライトは、神様も何に使うかわからないトークンを無駄にしているだけだよ。

テストに依存して「うまくいってる」と言ってるリライトをよく見るけど、PostgresやSQLiteが信頼できる理由は、主にテストじゃなくて、実際の運用での経験から来てるんだよね。信頼性は、何年も運用してきた結果なんだ。

Hacker Newsで議論の続きを見る