Lukas Vogel has ported the original 1993 Doom game to run entirely within a SQL database, with the game logic and rendering implemented as SQL queries. According to Vogel's blog post, the project runs the authentic Doom shareware episode using CedarDB, where SQL handles all game processing while a minimal Python client manages only input timing, keyboard reading, and display output. The implementation includes multiplayer support, with Vogel noting that 'Multiplayer also works' and demonstrating EU and US servers where players can join deathmatch games. The system separates concerns clearly: the Python client drives the game at 35 ticks per second, reads keyboard input, and displays the resulting bitmap, while all game state evolution and rendering occurs inside the database. Doom's WAD file format, which Vogel describes as 'highly relational,' was translated into database tables using approximately 1,000 lines of Python code, with importing the complete Doom 1 data taking about 18 seconds on his laptop. The game logic executes as a fixed 35 Hz loop using CedarDB's cedarscript language, which resembles PL/pgSQL. Each tick processes player input, enemy AI, item pickup, projectile movement, explosions, sprite rendering, animations, view bobbing, and HUD updates. Performance measurements show the most demanding tick (in level E4M1 with 46 awake monsters) takes 10.45 milliseconds—about 37% of the available 28.6 millisecond budget per tick—while typical ticks with fewer monsters average just 2.15 milliseconds or 8% of the budget. Despite initial complexity, the SQL implementation proves surprisingly compact. The game logic comprises approximately 5,900 lines of SQL, which Vogel notes is 'definitely less than the original C source code which does the same in about 9,000 lines.' The rendering pipeline uses about 1,300 lines of SQL across 89 Common Table Expressions (CTEs) per frame, roughly 2.5 times fewer lines than Linux Doom's 3,300-line rendering engine. Vogel reports that expressing game logic as SQL UPDATE statements with WHERE clauses finally made the Entity Component System (ECS) pattern 'click' for him, as each SQL operation naturally processes all matching entities in parallel. This effort builds on Vogel's earlier DOOMQL project, which implemented a Doom-like game in SQL but used raycasting (similar to Wolfenstein 3D) rather than Doom's actual BSP tree-based rendering. DOOMQL features a multiplayer-capable architecture where CedarDB handles player synchronization and state, with a minimal 150-line Python client for input/output. Together, these projects demonstrate SQL's viability for complex interactive applications, though Vogel acknowledges questions about whether such an approach represents good engineering practice.
This image shows the 89 Common Table Expressions (CTEs) executed per frame, as mentioned in the article's description of the SQL Doom rendering pipeline using about 1,300 lines of SQL across 89 CTEs.
This visualization supports the article's performance analysis, where the most demanding tick takes 10.45 ms (37% of frame budget) and typical ticks average 2.15 ms (8% of budget), as measured on the author's laptop.
This image confirms that the SQL-based Doom port correctly renders the original Doom's graphics, as stated in the article's introduction of the project running the authentic Doom shareware episode.