SQLDoom renders Doom with 1,300 lines of SQL — 89 CTEs as a game engine at 35fps

'Rendering Doom in a database is obviously a bad idea,' Lukas Vogel writes in the blog post explaining SQLDoom, his project rendering Doom using an SQL database. The architecture: a small Python client handles input, output, game timing and frame display, while behind it a series of CedarDB tables tracks the game geometry and state. The game itself is about 1,300 lines of SQL spread across 89 common table expressions, which implement the game logic and generate 35 bitmap framebuffers per second.

SQLDoom is a major step up from Vogel's previous DoomQL project, which last year set out to build 'a multiplayer Doom-like shooter entirely in SQL' but ended up with a raycasting-based, grayscale ASCII approximation. The 2026 version renders accurate bitmapped views of Hell at 35 fps, complete with a debug view showing performance statistics and pipeline details.

The stunt doubles as a database benchmark in disguise: rendering a frame means running query pipelines that consume the world-state tables every tick, which stresses query planning, common-table-expression evaluation and materialization far beyond typical OLTP workloads — which is precisely the point for the CedarDB team.

It answers 'can it run Doom' at the abstraction level, not the device level: not a port to new hardware, but new math — relational queries as a rendering pipeline.

The numbers make it real rather than conceptual: 1,300 lines of SQL, 89 CTEs, 35 frames per second of accurate bitmap output.

It builds on the author's own prior failure — DoomQL's ASCII raycaster — showing the gap between 'computationally possible in SQL' and 'engine-grade in SQL.'

For a database startup, Doom is a stress test that marketing materials can't fake: per-frame query pipelines expose planning and execution performance to anyone.

Engines are just computation pipelines; when you push a system past its intended abstraction — SQL as graphics pipeline — you learn exactly where its real limits are.

SQLDoom was published with a lengthy technical blog post and source on GitHub in October 2026; Ars Technica covered it the same week. The source reports no follow-up plans.