Doom Runs Inside an SQL Database at 35 FPS

A developer has rendered the original Doom entirely within an SQL database, achieving playable frame rates and full-color graphics. The project, named SQLDoom, uses about 1,300 lines of SQL queries spread across 89 common table expressions to implement game logic and generate 35 bitmap framebuffers per second.

Lukas Vogel detailed the work in a blog post, noting that a small Python client handles input, output, timing, and screen display. Behind that client, CedarDB tables track geometry and game state. Vogel wrote that converting Doom's classic WAD files to a relational database was relatively simple because the original game breaks levels into vertices, lines, sectors, and binary-space partition trees that map well to SQL structures.

The effort improves on Vogel's previous DoomQL project, which produced only raycasted grayscale ASCII graphics similar to Wolfenstein 3D. SQLDoom generates 640×480 frames that resemble the original executable's output. A simple "ORDER BY" statement on a pre-computed sort_key determines which wall parts to display each frame, boosting performance.

Rendering floors and ceilings proved trickier. Vogel described his solution as a "pretty hacky" replacement that iterates over an ordered list of panels, since the database cannot use the original engine's visplanes and column-by-column state mutations.

Despite the overhead of reading and writing SQL tables for every game element, Vogel reported about 60 fps on a Ryzen 7 laptop, with dips to 35 fps in busy scenes. He highlighted multiplayer advantages: the database provides a steady "reference snapshot" of game state with inherent concurrency and access handling, meaning "no partially applied updates, physics bugs, or disagreements over whether the rocket actually hit."

The code is available on GitHub for local use with CedarDB and a Doom WAD file. A free online hosted demo also exists, though Vogel noted poor performance in his test of that option.