SQLDoomは1,300行のSQLでDoomを描画 — 89個のCTEをゲームエンジンとして35fpsで動作

「データベースでDoomを描画するのは明らかに悪いアイデアだ」とLukas Vogelは、SQLデータベースを使ってDoomを描画する自身のプロジェクトSQLDoomを説明するブログ記事に書いている。アーキテクチャはこうだ。小さなPythonクライアントが入力、出力、ゲームのタイミング、フレーム表示を担い、その背後で一連のCedarDBテーブルがゲームのジオメトリと状態を追跡する。ゲーム自体は89個の共通テーブル式にまたがる約1,300行のSQLで、これがゲームロジックを実装し、毎秒35枚のビットマップフレームバッファを生成する。

SQLDoomは、Vogelの以前のプロジェクトDoomQLからの大きな前進だ。DoomQLは昨年「SQLだけでマルチプレイヤーのDoom風シューターを構築する」ことを目指して始まったが、最終的にはレイキャスティングに基づくグレースケールのASCII近似に終わった。2026年版は地獄の正確なビットマップビューを35fpsで描画し、パフォーマンス統計とパイプラインの詳細を示すデバッグビューも備えている。

この芸当は、実はデータベースのベンチマークを兼ねている。フレームを描画するとは、毎ティックにワールド状態のテーブルを消費するクエリパイプラインを実行することであり、これはクエリの計画、共通テーブル式の評価、マテリアライゼーションを、典型的なOLTPワークロードをはるかに超えて負荷をかける。まさにそれがCedarDBチームにとっての狙いなのだ。

クエリエンジンは計算エンジンである。ジオメトリと状態がテーブルにあれば、結合、CTE、集約がフレームごとの計算を行える。フレームバッファはクエリの結果なのだ。

これは「Doomを動かせるか」という問いに、デバイスレベルではなく抽象化レベルで答えるものだ。新しいハードウェアへの移植ではなく、新しい数学、すなわちレンダリングパイプラインとしてのリレーショナルクエリである。

数字がこれを概念ではなく現実のものにしている。1,300行のSQL、89個のCTE、毎秒35フレームの正確なビットマップ出力だ。

これは著者自身の過去の失敗、すなわちDoomQLのASCIIレイキャスターの上に築かれている。「SQLで計算的に可能」と「SQLでエンジン品質」の間の隔たりを示している。

データベースのスタートアップにとって、Doomはマーケティング資料では偽装できないストレステストだ。フレームごとのクエリパイプラインは、計画と実行のパフォーマンスを誰にでも明らかにする。

エンジンとは単なる計算パイプラインにすぎない。システムを本来の抽象化の範囲を超えて押し進めるとき、すなわちSQLをグラフィックスパイプラインとして使うとき、その本当の限界がどこにあるのかを正確に学ぶことができる。

SQLDoomは2026年10月に長編の技術ブログ記事とGitHub上のソースコードとともに公開された。Ars Technicaが同じ週に取り上げた。ソースによれば、今後の計画は報告されていない。