SQLでDoomを描画 1300行で35fpsを記録

Kyle Orland が Ars Technica で報じた記事に基づく。

“Rendering Doom in a database is obviously a bad idea,” Lukas Vogel writes in a lengthy blog post explaining how exactly he managed to render Doom using an SQL database.

OK, that’s not entirely accurate. The SQLDoom project uses a small Python client to handle input and output, drive the game’s timing, and display each frame to the screen. Behind that, a series of CedarDB tables tracks the game geometry and state, while about 1,300 lines of SQL queries spread across 89 common table expressions implement the game logic and generate 35 bitmap framebuffers per second.

編集部の見解

今回の事例は実用的な実行方式ではなく、関係データベースの表現力を示す検証事例と見る。状態の参照断面を保ちつつ同時実行を扱う発想は、多人数参加型処理の設計論に材料を提供すると評価する。今後3〜6か月では、個人開発者による再現や別種の基盤での追試が増えると見る。

1〜3年の視点では、処理を基盤に寄せる設計と専用処理層に分離する設計の境界が議論になると見る。描画のような逐次処理まで問い合わせ言語で記述する手法は、保守性や効率の観点で不利と評価する。一方で、状態管理と同時実行制御を基盤側に委ねる考え方は、協調作業支援機能に応用できる可能性があると見る。

どこまでを問い合わせ言語で担い、どこからを外部処理に任せるべきかという線引きが問われている。Canon EOS 550DにDoom移植、Magic Lanternでゲームプレイ可能に見られる移植事例と同様に、実行可能であることと適切であることは別と評価する。制約の厳しい環境で動作させる試みにどのような技術的意義を認めるべきかという点が、今後の論点になると見る。

参考

• 「Someone got Doom in an SQL database」, by Kyle Orland — Ars Technica, 2026-10-02T21:19:05.000Z (CC BY-NC-ND)
• 元記事URL: https://arstechnica.com/gaming/2026/10/can-it-run-doom-sql-database-edition/