SQLDoom Runs the Classic Doom Game Engine Inside a Database

“Rendering Doom and storing it in a database is clearly a bad idea,” writes Lukas Vogel. Yet in a detailed blog post, Vogel explains how he used SQL to accurately render Doom.

That description is not entirely accurate. The SQLDoom project uses a small Python client to handle input and output, control the game’s timing, and display each frame on screen. Behind the scenes, a series of CedarDB tables track the game’s geometry and state, while approximately 1,300 lines of SQL queries implement the game’s logic and generate 35 bitmap framebuffers per second.

SQLDoom is a significant improvement over Vogel’s earlier work. His previous DoomQL project, published last year, aimed to build a “multiplayer Doom-like shooter game entirely in SQL.” That project produced raycasting-based grayscale ASCII graphics resembling a simplified, right-angled map from Wolfenstein 3D. The new SQLDoom, by contrast, produces full-color 640×480 frames that look like they came from the original Doom executable.

Turning Doom’s Game World Into Database Tables

Converting classic Doom WAD files into a relational database was relatively straightforward, Vogel writes, because the original game divided its levels into elements such as vertices, lines, and sectors.

The game’s famous binary space partition tree can also be represented in SQL using each object’s sort_key, which is precomputed for every position when the data is loaded. Storing this information in a table improves performance: a simple ORDER BY statement determines, on a frame-by-frame basis, which parts of a wall should be displayed and which can be ignored.

The result is an unusual but technically impressive experiment: a playable rendering pipeline in which much of Doom‘s geometry, state, and game logic are processed through SQL queries.