Developer Lukas Vogel has built SQLDoom, a working reimplementation of the original 1993 Doom that moves both the game logic and rendering pipeline into a SQL database. The project runs inside CedarDB and uses roughly 5,900 lines of SQL for Doom’s game logic, compared with around 9,000 lines in the original implementation. Its renderer adds another roughly 1,300 lines of SQL spread across 89 common table expressions.
SQLDoom is not literally running without any conventional code outside the database. A small Python client handles keyboard input, game timing and displaying the finished bitmap, while the game state, logic and renderer live inside CedarDB. The Python driver triggers a game tick 35 times per second, preserving Doom’s original gameplay timing, while rendering can run separately and produce the complete 320×200 framebuffer at up to 60 Hz on ordinary laptop hardware.
Vogel describes the project as a more complete successor to DOOMQL, an earlier experiment that implemented a Doom-like multiplayer shooter using SQL but relied on a simplified raycasting renderer with ASCII-style visuals. SQLDoom instead loads real Doom WAD data and recreates substantially more of the original engine, including textures, BSP traversal, sprites and the underlying gameplay systems. The source code is publicly available under the GPL, though the project does not distribute Doom’s copyrighted WAD files.
One reason the experiment works at all is that Doom’s level format already maps surprisingly well onto relational data. Vertices, linedefs, sectors and other pieces of map geometry can be represented as database tables, while SQL queries can transform and filter that information to determine what should appear on screen. Vogel’s renderer ultimately produces 64,000 rows representing individual pixels before combining them into a single RGB framebuffer returned to the client.
The rendering query itself is considerably more elaborate than a typical database workload. Its 89 CTEs handle tasks including traversing Doom’s BSP structure, clipping geometry, projecting walls into screen space, rendering floors and ceilings, processing sprites and resolving which fragment should occupy each pixel. Vogel notes that the original Linux Doom renderer contains roughly 3,300 lines of source code excluding comments, making SQLDoom’s approximately 1,300-line renderer unexpectedly compact despite using a language never intended for this job.
The gameplay side takes advantage of SQL’s ability to update sets of entities at once. A typical game tick with six active monsters reportedly takes around 2.15 milliseconds, while one of Vogel’s heavier measurements reached about 10.45 milliseconds on E4M1 with 46 monsters active. That leaves the database comfortably within the approximately 28.6-millisecond budget required to maintain Doom’s original 35-tick-per-second simulation rate.
SQLDoom belongs to the same class of technically unnecessary but revealing engineering projects that push familiar software far outside its intended use. Developers have similarly built unusual tools such as a 3D source-code visualizer capable of handling millions of lines and brought old console software to unexpected hardware through projects like native original Xbox emulation on a jailbroken PS5. In each case, the practical value is secondary to demonstrating what the underlying technology can be made to do.
SQLDoom also includes multiplayer support and can be run locally by users with CedarDB Community Edition, Python and a compatible Doom IWAD. Vogel has additionally provided live demonstrations, allowing the project to be tested without building the full environment from scratch. While nobody is likely to choose a relational database as the foundation of a commercial first-person shooter, SQLDoom shows that even Doom’s real-time game loop and software renderer can be expressed through database operations with surprisingly respectable performance.
