SQLDoom 以 1,300 行 SQL 渲染 Doom — 89 個 CTE 組成的遊戲引擎，達 35fps

「在資料庫裡渲染 Doom 顯然是個壞主意，」Lukas Vogel 在解釋 SQLDoom 的部落格文章中寫道；這個專案利用 SQL 資料庫來渲染 Doom。其架構是：一個小型 Python 用戶端負責輸入、輸出、遊戲計時與畫面顯示，而在其背後，一系列 CedarDB 資料表追蹤遊戲幾何與狀態。遊戲本身約有 1,300 行 SQL，分散於 89 個通用資料表運算式（common table expression），這些運算式實作遊戲邏輯，並每秒產生 35 個點陣圖影格緩衝區。

SQLDoom 相較於 Vogel 先前的 DoomQL 專案是一大躍進；DoomQL 去年以「完全用 SQL 打造一款多人 Doom 風射擊遊戲」為目標，最終卻只做出以光線投射為基礎的灰階 ASCII 近似版本。2026 年的版本以 35 fps 渲染出精確的地獄點陣圖視野，並附有顯示效能統計與管線細節的除錯檢視。

這項噱頭同時也是一場偽裝的資料庫基準測試：渲染一個影格意味著每個 tick 都要執行查詢管線、消耗世界狀態資料表，這對查詢規劃、通用資料表運算式求值與具體化（materialization）造成的壓力遠超典型 OLTP 工作負載——而這正是 CedarDB 團隊的目的。

查詢引擎就是運算引擎：若幾何與狀態存在資料表中，聯結、CTE 與聚合就能完成逐格運算——影格緩衝區就是一個查詢結果。

它在抽象層面而非裝置層面回答了「它能跑 Doom 嗎」：這不是移植到新硬體，而是新的數學——以關聯式查詢作為渲染管線。

數字讓它成為現實而非概念：1,300 行 SQL、89 個 CTE、每秒 35 個精確點陣圖輸出影格。

它建立在作者自身先前的失敗之上——DoomQL 的 ASCII 光線投射器——顯示出「在 SQL 中運算上可行」與「在 SQL 中達到引擎級」之間的差距。

對一家資料庫新創公司而言，Doom 是行銷素材無法偽造的壓力測試：逐格查詢管線讓任何人都能檢視規劃與執行效能。

引擎不過是運算管線；當你把系統推離其預定的抽象層級——以 SQL 作為圖形管線——你就能確切了解它真正的極限在哪裡。

SQLDoom 於 2026 年 10 月發布，附有一篇詳盡的技術部落格文章與 GitHub 上的原始碼；Ars Technica 於同週報導。來源未提及後續計畫。