"Rendering Doom in a database is obviously a bad idea," Lukas Vogel writes. He did it anyway.
SQLDoom, built by the CedarDB co-founder, runs the original Doom with a small Python client handling input, timing and pushing finished frames to the screen. Behind that, CedarDB tables hold the game geometry and state, and roughly 1,300 lines of SQL — spread across 89 common table expressions — implement the game logic and emit 35 bitmap framebuffers per second. The result is full-colour 640×480 frames that look like they came out of the 1993 original, rather than the grayscale ASCII raycasting of Vogel's earlier DoomQL experiment.
A relational database turns out to be a decent home for Doom's data. The game's WAD files were already broken into vertices, lines and sectors, so loading levels is mostly a matter of tables. Even the binary-space partition trees translate: a sort_key precomputed for each position lets a plain "ORDER BY" decide which wall slices to draw each frame. Floors and ceilings were the awkward part, handled with what Vogel calls a "pretty hacky" ordered panel iteration instead of the original's visplanes.
Performance is better than the premise deserves: about 60 frames per second on a Ryzen 7 laptop, dipping to 35 in busy scenes. And the database has an unexpected argument in its favour for multiplayer — a consistent snapshot of the world means no partially applied updates, no physics bugs, and no arguments over whether the rocket actually hit.
The code is on GitHub, and running it locally needs a CedarDB copy and a Doom WAD file; there is also a hosted demo match. Ars Technica reported the project this week. It is the latest entry in the long tradition of running Doom on hardware and software that was never meant to run it.




