Doom Rendered in SQL Hits 35fps With 1,300 Lines
Quotes and commentary based on Kyle Orland's Ars Technica report on rendering Doom in SQL.
Based on an article reported by Kyle Orland for 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.
Editorial Opinion
We view this case not as a practical execution method, but as a test case demonstrating the expressive power of relational databases. We assess the idea of handling concurrency while preserving a consistent snapshot of state as providing material for design theory on multiplayer processing. We expect reproductions by independent developers and follow-up tests on other platforms to increase over the next 3-6 months.
From a 1-3 year perspective, we expect debate over the boundary between designs that push processing into the platform and designs that separate it into a dedicated processing layer. We assess describing even sequential processes such as rendering in a query language as disadvantageous in terms of maintainability and efficiency. At the same time, we see potential to apply the idea of delegating state management and concurrency control to the platform side to collaborative features.
At issue is where to draw the line between what should be handled by the query language and what should be left to external processing. As with the port described in Doom Ported to Canon EOS 550D, Playable With Magic Lantern, we assess that being possible is distinct from being appropriate. We see the question of what technical significance should be accorded to attempts to run software in highly constrained environments as a future point of discussion.
References
- “Someone got Doom in an SQL database”, by Kyle Orland — Ars Technica, 2026-10-02T21:19:05.000Z (CC BY-NC-ND)
- Source URL: https://arstechnica.com/gaming/2026/10/can-it-run-doom-sql-database-edition/
Frequently Asked Questions
- Is there any significance in attempts to run games on a relational database?
- We see the significance in validating expressive power rather than practicality. We assess that implementations in highly constrained environments clarify the boundary of task division. We see the accumulation of derivative experiments as useful for debate on design theory.
- Can the idea of delegating state management to the platform be applied in practice?
- We see it as informative in areas such as concurrency control and shared state. We assess that there is no need to push all processing into the query language. We see room for application in features handling shared state, such as collaborative work support.
Comments