Someone Put Doom Inside an SQL Database — and It Actually Works

Someone has put Doom inside an SQL database, and it actually works. Lukas Vogel, the developer behind the project, calls the result SQLDoom, and it renders full-color frames at 35 frames per second using nothing but SQL queries. The setup is absurdly literal: the game geometry, state, and rendering logic all live in tables, with about 1,300 lines of SQL queries spread across 89 common table expressions doing the heavy lifting.

The project is a direct sequel to Vogel’s earlier DoomQL, which attempted to build “a multiplayer Doom-like shooter entirely in SQL.” That experiment produced raycasting-based, grayscale ASCII graphics that looked more like the simplistic 90-degree-angled maps of Wolfenstein 3D than anything resembling Doom’s actual look. SQLDoom, by contrast, generates full-color 640×480 frames that could pass for the original game’s output.

How SQLDoom Works

The system is not purely SQL. A small Python client handles input and output, drives the game’s timing, and displays each frame to the screen. Behind that, a series of CedarDB tables tracks the game geometry and state. The SQL queries themselves do the rendering, generating 35 bitmap framebuffers per second.

The conversion process was relatively simple, Vogel writes, because of how the original Doom breaks levels down into vertices, lines, sectors, and so on. Even Doom’s famous binary-space partition trees can be broken down into SQL using a sort_key for objects that is pre-computed for each position at load time. With that set in your table, a simple “ORDER BY” statement determines which parts of walls to display and which to ignore, vastly improving performance.

The Python client is limited to handling input/output and display. Everything else — the geometry, the state, and the rendering logic — lives in the database. The queries are the engine, and the Python client is just the driver.

From DoomQL to SQLDoom

The comparison between the two projects is instructive. DoomQL was an attempt to rebuild the entire game engine in SQL, including multiplayer support. The result was a proof of concept that worked, but it was ugly. SQLDoom takes a different approach: it uses SQL for rendering and state tracking, but relies on Python for everything else.

The table shows the shift clearly. DoomQL was a proof of concept that worked, but it was ugly. SQLDoom is a proof of concept that looks good.

Why SQL Is the Right Tool Here

The key insight is that Doom’s geometry is already structured like a database. Levels are built from vertices, lines, and sectors. The binary-space partition trees can be translated into a sort_key that SQL’s “ORDER BY” function can use efficiently.

This means the database is doing the heavy lifting for visibility. Each frame is generated by querying the geometry tables, sorting the visible elements, and rendering the result. The Python client handles the input/output and display, but the actual rendering is done by SQL.

The SQL queries are not just a novelty. They are the rendering engine. The Python client is the user interface. The database is the game.

What the Numbers Mean

The numbers tell the story. About 1,300 lines of SQL across 89 common table expressions drive the entire rendering pipeline. That is a lot of code, but it is also a remarkable achievement. The 35 frames per second figure is notable because it comes from SQL queries alone.

The project achieves something genuinely novel: a fully functional Doom renderer that lives entirely in SQL. The Python client handles the edges, but the heart of the rendering is pure SQL.

The Practical Limits

SQLDoom is a demonstration, but it shows what is possible. It requires a database backend, a Python environment, and a willingness to stare at raw SQL for hours. The ASCII predecessor showed that the concept was possible. SQLDoom shows that it can be beautiful.

The project is also a reminder that the tools we use are not fixed. Games are built from data, and data can be queried. The gap between a game and a database is smaller than it seems.

Why This Matters

The project is a technical curiosity, but it also has practical value. It shows how existing game assets can be repurposed for new platforms. A WAD file contains level data, and SQLDoom demonstrates that that data can be mapped to a database schema.

The performance figures are modest by modern standards, but the project achieves something genuinely novel: a fully functional Doom renderer that lives entirely in SQL. The Python client handles the edges, but the heart of the rendering is pure SQL.

The Verdict

SQLDoom is a clever hack, and it works. Vogel’s project takes a game that was built for speed and rebuilds it as a literal database query, and the result holds together. The performance is steady, and the underlying technology is genuinely unusual.

The project is a reminder that creativity in software often comes from unexpected directions. Vogel pushed SQL to the point where the game renders itself from queries.

The result is a working Doom renderer that runs on SQL, and that is worth celebrating on its own terms.

Source material: “Someone got Doom in an SQL database,” Ars Technica.

DOOM · Game Development · open-source · Python · SQL