Developer runs Doom by processing pure SQL queries in a database

Lukas Vogel has achieved what most would consider the definition of a terrible technical decision: running Doom inside an SQL database. His detailed writeup walks through the architecture behind this improbable feat.

How it actually works#

The SQLDoom project isn't purely a database implementation. A lightweight Python client sits on top, handling user input, managing frame timing, and displaying the rendered output. The real heavy lifting happens in a backend layer of CedarDB tables that store the game's geometry and state data. Approximately 1,300 lines of SQL code, structured across 89 common table expressions, carry out all the game mechanics and produce 35 bitmap frames each second.

A leap forward from the previous attempt#

This venture represents a significant step up from Vogel's earlier DoomQL experiment, which attempted to build "a multiplayer Doom-like shooter entirely in SQL." That version rendered the world in grayscale ASCII art using raycasting—it bore more resemblance to the simplistic corridor-based geometry of Wolfenstein 3D. By contrast, the new SQLDoom generates vivid color graphics at 640×480 resolution that closely resemble output from the authentic Doom engine.

Why the database approach works#

Converting Doom's original WAD map files into relational tables proved surprisingly efficient, Vogel explains, because the game already represented levels as discrete components: vertices, lines, sectors, and other modular building blocks. Even the classic binary-space partition trees that Doom used for rendering optimization translate cleanly into SQL. By pre-computing a sort key for objects at each position during startup and storing it in a table, a single "ORDER BY" query can instantly determine which wall surfaces are visible each frame—eliminating unnecessary rendering and boosting performance significantly.