Developer Renders Doom Inside an SQL Database at 35 FPS

Developer Lukas Vogel built a working renderer for the original 1993 shooter Doom that runs entirely on SQL database queries, producing full-color 640x480 frames at up to 60 frames per second, according to a blog post detailed by Ars Technica. The project, called SQLDoom, uses roughly 1,300 lines of SQL spread across 89 common table expressions to generate Doom's game logic and bitmap frames.

What is SQLDoom and who built it?

SQLDoom is Vogel's second attempt at squeezing Doom into a relational database. His earlier project, DoomQL, set out to build "a multiplayer Doom-like shooter entirely in SQL" but ended up with grayscale, raycasted graphics closer to Wolfenstein 3D than Doom, Vogel writes in the post cited by Ars Technica. SQLDoom instead produces frames that resemble output from the original Doom executable, running on CedarDB tables behind a small Python client that handles input, output, and screen display.

How does a database render a first-person shooter?

Vogel converted Doom's original WAD level files into relational tables, a task he describes as "relatively simple and straightforward" because the game already breaks levels into vertices, lines, and sectors. Even Doom's binary-space partition trees translate into SQL through a pre-computed sort_key value for each object's position, loaded at startup. A single ORDER BY statement then determines, frame by frame, which wall segments to draw and which to cull, according to the post.

How fast does it actually run?

Vogel told Ars Technica he measured SQLDoom running at about 60 frames per second on a Ryzen 7-powered laptop, with dips to roughly 35 fps during visually busy scenes. That performance holds despite the overhead of reading and writing to SQL tables for every element of the game state on every frame.

What technical problems did he have to solve?

The hardest piece was floors and ceilings. Doom's original engine renders those surfaces column by column using "visplanes" and state mutations that do not map cleanly onto SQL queries, Vogel writes. His workaround, which he calls "pretty hacky," iterates over an ordered list of panels instead of replicating the original approach exactly.

Why put a shooter inside a database at all?

Vogel argues the exercise has a practical upside for multiplayer play. A database's built-in concurrency and access controls give every connected player the same consistent snapshot of game state, he says: "no partially applied updates, physics bugs, or disagreements over whether the rocket actually hit." Source code for anyone who wants to run SQLDoom locally is referenced in the original post.

For readers tracking other experiments at the edge of gaming hardware and software, HTT News has also covered adaptive gaming peripherals shown at a Saudi exhibition.