Doom’s New Home Is a Database
Doom just found a new home: a database. SQLDoom, a project by Lukas Vogel at CedarDB, is not merely a game storing high scores in a database or a visual imitation. It’s a full reimplementation of the original 1993 Doom, with its core game logic and graphics rendering executing entirely in SQL.
This architecture is elegantly decoupled. Game logic and the rendering engine run as SQL queries, while Python acts as a lightweight bridge. Python's role is limited to capturing keyboard input, managing the game loop’s timing, and displaying the resulting frame buffer. Every frame you see is the output of a single, massive SQL query.
The scale of this undertaking is impressive. The game’s 320x200 resolution, totaling 64,000 pixels, is calculated by the renderer, which comprises approximately 1,300 lines of SQL across about 89 Common Table Expressions (CTEs). The game logic adds another 5,900 lines of SQL. This entire SQL codebase is notably shorter than the original Doom's roughly 9,000 lines of C game logic.
One Query Paints 64,000 Pixels
Every frame rendered in SQLDoom originates from a single, complex database query. This query calculates the color for each of the 64,000 pixels (320 × 200 resolution) on screen, returning the image as raw bitmap data, with one row representing each pixel. The rendering query alone spans approximately 1,300 lines of SQL, utilizing about 89 Common Table Expressions (CTEs).
Relational operations fundamentally differ from traditional procedural code. Instead of explicit loops iterating through game objects, SQLDoom leverages set-based operations to process entities collectively. This allows a single UPDATE statement, for instance, to modify all monsters' states simultaneously, a stark contrast to the original C implementation’s numerous for or while loops.
Performance metrics are impressive for a database-native game. The core game logic adheres to Doom’s original 35 tics per second, ensuring authentic gameplay pacing. However, the renderer can achieve up to 60 frames per second (FPS) on modern hardware by interpolating camera positions between these game ticks, providing a smoother visual experience than the 1993 original. Lukas Vogel at CedarDB has effectively demonstrated SQL's surprising capability as a game engine.
The Database Does the Heavy Lifting
Rendering Doom in a database presents a fascinating trade-off. The original 1993 engine, engineered by John Carmack, masterfully conserved CPU cycles with Binary Space Partitioning (BSP) trees to determine visibility. SQLDoom, by contrast, brute-forces depth and occlusion calculations across its 64,000 pixels per frame. This makes visibility the slowest part of the SQL rendering pipeline.
This brute-force approach is only viable thanks to CedarDB’s architecture. Its query engine compiles SQL queries directly to LLVM IR and then to native machine code, allowing complex analytical workloads to execute with impressive speed—up to 60 frames per second on a laptop. This compilation is crucial for handling the 1,300 lines of SQL in a single rendering query, as described in the project’s blog post: We Ported the Original Doom to SQL - CedarDB.
The game world itself transforms into structured data. Doom’s iconic WAD assets, which define everything from map geometry to textures, find new homes as relational tables. This includes:
- Maps
- Sectors
- Linedefs
- Textures
Even individual items like the shotgun become rows in a table, allowing direct SQL manipulation to change game mechanics, such as updating a weapon to fire 500 pellets with a simple UPDATE statement. This makes the entire game world queryable and modifiable through standard database operations.
Enjoying this? Get one like it in your inbox each morning.
one email a day · unsubscribe in two clicks · no third-party tracking
When Game Mechanics Become Editable Rows
Unusual design also yields surprising payoffs. Because weapons and player stats reside as table data, a single SQL update can alter a shotgun’s pellet count or a player’s base health. This demonstrates the database’s dynamic capabilities, though a live match would restrict such direct manipulation.
Multiplayer functionality emerges naturally from database transactions. Each game tick processes as an isolated transaction, ensuring all players query a consistent, synchronized view of the game world. Restricted functions prevent clients from directly altering protected values, such as their own health, maintaining game integrity.
SQLDoom transcends mere novelty, serving as a rigorous testbed for database query engines as compute platforms. This project builds on Lukas Vogel’s earlier ASCII raycasting prototype, DOOMQL, pushing the boundaries of what relational databases can achieve. SQLDoom invites us to reconsider how other complex game mechanics could be represented and executed as pure data and queries.
Frequently Asked Questions
What is SQLDoom?
SQLDoom is a project by Lukas Vogel at CedarDB that reimplements Doom’s game logic and graphics rendering in SQL.
Does SQLDoom run entirely in SQL?
The game logic and renderer run in SQL. Python handles keyboard input, timing, and displaying the rendered frame.
How many pixels does SQLDoom render per frame?
It calculates 64,000 pixels per frame, matching Doom’s 320-by-200 resolution.
How does SQLDoom handle multiplayer?
Game ticks run as database transactions, giving players a synchronized view of the shared game state.