스크립트
00:00:00PostgresがRustで書き直されました。リリース版は、なんと46,000件ものPostgres回帰テストをすべてパスしています。
00:00:08標準のpsqlで動作し、既存のPostgres 18.3のデータディレクトリを読み込むことさえ可能です。
00:00:14これを聞くと本番運用できそうに聞こえますが、実際はそうではありません。
00:00:17しかし、このプロジェクトの最もエキサイティングなバージョンは、まだリリースされていません。
00:00:21一体何が起きているのでしょうか？これはPostgresの未来なのか、それとも単なるAIの実験なのか。
00:00:30なぜこれが重要なのかを理解するには、まず現状の問題を知る必要があります。
00:00:36正直に言って、Postgresはこれまでで最高のデータベースの一つです。
00:00:40しかし、40年近い歴史と約100万行のC言語によるコードが蓄積されています。
00:00:46すべてのクライアント接続ごとにバックエンドプロセスが生成されます。
00:00:49その分離は有益ですが、メモリ消費量が増え、接続プーリングへの依存が高まり、
00:00:56並列処理において状態を共有するのが難しくなります。
00:01:00PGRustは異なる道を選びました。
00:01:02Postgresの動作、クライアント体験、ディスクフォーマットを維持しつつ、内部エンジンをRustで置き換えるのです。
00:01:09これはPostgresの拡張機能ではありません。
00:01:11上に機能を追加しているわけでもありません。
00:01:13これは完全に別個の実装であり、Postgresのように振る舞うことを目指しているのです。
00:01:18最近はRustへの書き直しが多く見られます。以前取り上げたBunがコードベース全体をRustで書き直したように。
00:01:25リンクをどこかに載せておきますね。
00:01:27さて、これらは聞こえが良いですが、実際にPostgresとして機能するのでしょうか？
00:01:31テストが不十分な点はあります。
00:01:32ワークフローを高速化するコーディングツールが好きなら、ぜひチャンネル登録を。
00:01:36常に動画を公開しています。
00:01:38では、公式のDockerイメージから始めて、通常のpsqlクライアントで接続してみます。
00:01:43カスタム設定なしで。
00:01:44接続できました。
00:01:46まず、バージョンを確認します。
00:01:48見ての通り、PGRustと表示され、最新版が稼働しています。
00:01:53では、テーブルを作成し、データを挿入して、クエリプランを確認してみましょう。
00:01:59ターミナルでそのまま実行します。
00:02:01外部から見ると、これはPostgresと全く見分けがつきません。
00:02:05同じクライアント、同じSQL、同じ出力。
00:02:08クエリプランナーがインデックススキャンを選択し、実際の実行統計を出していることさえわかります。
00:02:14では、もう少し面白くするために、10万行のデータを挿入して別のクエリを実行してみましょう。
00:02:20これは10万行のデータを生成しただけのものです。
00:02:23これをここに入力します。
00:02:25結局、これにはどんな意味があるのでしょうか？
00:02:27良い質問ですね。
00:02:28この初期リリース版では、通常のPostgresと比べて劇的な速度向上は見られません。
00:02:35パフォーマンスに関する主張は、まだ未リリースの開発版において、スレッドごとの接続モデルへの切り替えによって実現されます。
00:02:43しかし、これが単なる部分的な実装ではないことは証明されています。
00:02:4746,000以上のクエリを含む、公式のPostgres回帰テストスイートを完全にパスしています。
00:02:53本物の通信プロトコルに対応し、クエリプランナーとストレージエンジンも機能しています。
00:02:59これはまぎれもないデータベースサーバーです。
00:03:01ただRustで書かれているというだけです。
00:03:03この開発が進むことで、スピードの面でかなりのパフォーマンス向上が見込めるかもしれません。
00:03:08では、なぜPostgresの拡張機能として作らなかったのでしょうか？
00:03:12なぜなら、拡張機能はPostgresのオリジナルのコアの上に載るものだからです。
00:03:16フォークすればコアを変更できますが、そうなると同じアーキテクチャを引き継ぎ、上流のPostgresに追従するという恒久的な作業が必要になります。
00:03:25CockroachDBやYugaByteのようなデータベースもありますが、これらは独立した分散型データベースです。
00:03:31完全な互換性は彼らの主な目標ではありません。
00:03:35PGRustは別のことを試みています。
00:03:37実際のPostgresの動作を仕様としているのです。
00:03:41現在のリリース版はPostgres 18.3をターゲットにしています。
00:03:44デフォルトの回帰スイートと分離テストをパスしており、既存のPostgres 18.3のデータディレクトリから起動できるほど互換性があります。
00:03:53より大きな実験は、別の公開されていないバージョンで行われており、そこではPostgresの「接続ごとにプロセス」というモデルが「接続ごとにスレッド」というモデルに置き換えられています。
00:04:05通常のPostgresモデルでは、各接続に独自のプロセスが割り当てられます。
00:04:09新しいモデルでは、各接続は同一プロセス内のスレッドを取得します。
00:04:14これにより、接続ごとのオーバーヘッドを削減し、データベースの異なるパーツ間で情報を共有しやすくなる可能性があります。
00:04:21しかし、これにはトレードオフがあるはずですよね？
00:04:24個別のプロセスは接続間の有用な壁も作り出しています。
00:04:28もし一つのプロセスが失敗しても、その分離によってダメージを抑えることができます。
00:04:32スレッドの場合、一つの安全でない拡張機能やメモリのバグがサーバー全体に影響を与える可能性があります。
00:04:38ですから、「接続ごとにスレッド」が自動的に優れているわけではありません。
00:04:41新しい扉を開く一方で、いくつかの安全策を失う可能性もあります。
00:04:45そして、この話には2つ目の重要な側面、AIがあります。
00:04:49Michael MaliceとJason Siebelは、この書き直しを加速させるためにコーディングエージェントを多用しました。
00:04:54公開版は意図的に、多くの箇所でオリジナルのPostgres構造に従っています。
00:04:59未公開版では、より大規模なアーキテクチャの変更を試みています。
00:05:03つまり、本当の実験は単に「RustはPostgresを速くできるか？」ということではありません。
00:05:08「AIはこれほどの大規模な書き直しを、開発者が基盤となるアーキテクチャを実際に再考できるほど手頃なものにできるか？」という問いに近いのです。
00:05:16AIがここで大いに活用されたからです。
00:05:19さて、これで状況は変わるのでしょうか？
00:05:20そうかもしれません。
00:05:21ここでもう少し慎重になる必要があります。
00:05:25リリース版はそれほど最適化されていません。
00:05:28主要なパフォーマンスの主張は、未公開の「接続ごとにスレッド」バージョンによるものですが、今はまだテストできません。
00:05:36開発者はトランザクションワークロードで約50%の性能向上を主張しています。
00:05:40また、分析ワークロードではPostgresの約300倍の性能を主張しています。
00:05:45これらの数字は巨大ですが、その結果の裏にあるコードは現在、検証やベンチマークのために公開されていません。
00:05:53というわけで、まだ多くの憶測が飛び交っています。
00:05:57オンラインで見かける反応は、このような疑問を含め、きれいに50対50で割れているようです。
00:06:03これらはGitHub上のIssueです。
00:06:05このようなIssueもありますよね。
00:06:08これは完全にまっとうな質問です。
00:06:10このIssueを読み進めると、開発者はこれを実現することに固執しているようです。
00:06:15ですので、まだ正確な統計はありません。
00:06:17とはいえ、数字が嘘だと自動的に決まったわけではありません。
00:06:20確定した事実ではなく、有望な主張として扱うべきだということです。
00:06:24正直なところ、正確な倍率は最も重要な部分ではないかもしれません。
00:06:28アイデアが実際に機能するかどうかを知るために、Postgresプロジェクト全体を変更する必要はないのです。
00:06:34その自由は、私たちが得られるどんな単一のベンチマークよりも価値があるかもしれません。
00:06:38さて、Rustでの書き直しに対する開発者からの反応は、このPGRustにおいても絶大です。
00:06:44Hacker Newsのメインの議論は何百ものポイントとコメントを集めましたが、やはり意見は割れています。
00:06:50どちらの側も良い点を突いています。
00:06:52まず、すべての回帰クエリをパスしたことは重大な功績です。
00:06:56Postgres互換であると主張するプロジェクトは多くあります。
00:06:59その言葉にはどんな意味でも含まれ得ます。
00:07:01PGRustには測定可能なターゲットがあります。
00:07:04本物のPostgresテストがその判断を下すのです。
00:07:07また、この書き直しのスピードは、コーディングエージェントが大規模なインフラ実験のコストを根本的に変える可能性があることを示唆しています。
00:07:13かつては試すには高すぎると思われていたアイデアが、今や現実味を帯びてきているのです。
00:07:19一方、回帰テストをパスすることは本番環境の信頼を得ることとは別物です。
00:07:24それらのテストは、何年ものクラッシュリカバリやレプリケーションテスト、あるいは何ヶ月も停止せずに動くデータベースには代えられません。
00:07:31どんな既知のテストもパスしても、誰も考えつかなかったような状況で失敗する可能性はあります。
00:07:37何十万行ものコードを生成することは一つの課題です。
00:07:42拡張機能の互換性も別の大きな溝です。
00:07:45さて、本番のPostgresクラスタをPGRustに置き換えるべきでしょうか？
00:07:49いいえ、絶対にダメです。
00:07:51プロジェクト自体がまだ本番運用レベルではありません。
00:07:53それは明記されています。
00:07:54完全には最適化されていません。
00:07:56拡張機能エコシステムを含む主要な互換性分野において、まだ未完成なのです。
00:08:02ですが、試してみるべきでしょうか？
00:08:03もちろんです。
00:08:03データベース、Rust、クエリ実行、互換性テスト、AI開発に関わっているなら、試さない手はありません。
00:08:10Dockerイメージを走らせ、クライアントライブラリをテストし、ソースを読み、何が起こるか確かめてみてください。
00:08:16というわけで、コメント欄にあなたの評価を書き込んでください。
00:08:18このプロジェクトはどこへ向かうのでしょうか？
00:08:20私たちはRustでの書き直しをさらに始めるのでしょうか？
00:08:21これからわかります。
00:08:23このようなコーディングのヒントやコツが好きなら、ぜひBetterStackチャンネルを登録してください。
00:08:26また別の動画でお会いしましょう。