- Published on
Someone got Doom in an SQL database
- Authors
- Name
- DeepHorus
Doom, the classic 1993 first-person shooter, has once again been rendered in an unlikely place: an SQL database. Developer Lukas Vogel revealed the project, called SQLDoom, in a lengthy blog post, opening with the candid admission that "rendering Doom in a database is obviously a bad idea." Despite that disclaimer, the project works, producing full-color 640x480 frames that closely resemble output from the original Doom executable. It represents a significant technical leap over Vogel's earlier effort and has drawn attention from developers fascinated by unconventional computing experiments.
The setup is not purely SQL, though the bulk of the work happens there. A small Python client handles input and output, manages game timing, and displays each frame to the screen. Behind that interface, a series of CedarDB tables stores the game's geometry and state, while approximately 1,300 lines of SQL queries spread across 89 common table expressions implement the game logic. Together, these queries generate 35 bitmap framebuffers per second, delivering playability that approaches the original's smoothness.
This is not Vogel's first attempt at putting Doom into SQL. Last year, he built DoomQL, described as "a multiplayer Doom-like shooter entirely in SQL." That project, however, produced raycasting-based, grayscale ASCII graphics more reminiscent of the simplistic 90-degree-angled maps of Wolfenstein 3D than of Doom itself. SQLDoom corrects those shortcomings, generating rich, full-color frames at a resolution that could have come straight from id Software's original build.
Converting Doom's classic WAD files into a relational database proved relatively straightforward, Vogel writes, thanks to how the original game structured its levels. Doom breaks maps down into vertices, lines, and sectors, data that maps naturally onto database tables. Even the game's famous binary-space partition trees can be represented in SQL through a pre-computed sort_key assigned to each object's position at load time.
That sort_key is central to the project's performance. With it in place, a simple ORDER BY statement determines each frame which wall segments should be displayed and which should be culled. This approach to visibility determination is what allows the database to sustain 35 frames per second, avoiding the exhaustive per-pixel computations that typically sink database-based rendering experiments.
The implications extend beyond novelty. SQLDoom demonstrates that complex, real-time graphical workloads can be expressed declaratively within modern analytical databases, pushing CedarDB far beyond its intended use cases. By showing that relational queries can handle geometry, visibility, and frame generation simultaneously, Vogel highlights capabilities that database vendors rarely benchmark.
Enthusiasts online have reacted with a mixture of amusement and admiration, echoing Vogel's own wry tone about the project's questionable premise. Whether SQLDoom inspires further experiments in database-driven graphics remains to be seen, but it has firmly joined the long tradition of developers asking not whether Doom can run somewhere, but whether it should.
