A programmer created SQLDoom, a project that runs Doom inside a SQL-backed stack, using queries to drive gameplay and rendering.
A Python helper handles timing, input, and translating database results into on-screen frames.
Performance ranges from 35 to 60 frames per second depending on hardware and scene complexity.
Quick read · 1 min
A programmer has ported Doom to run inside a SQL database, with game rules and rendering driven by SQL queries and a small Python layer for timing and display. The project, SQLDoom, uses about 1,300 lines of SQL across 89 query blocks to render 640×480 frames. On some hardware it can reach around 60 fps, dropping to about 35 fps in busy scenes. It’s a clever tech demo rather than a practical game release, but it shows how flexible databases can be for modeling real-time processes. If you want to try it, you can run the code locally with CedarDB and Doom data, or join hosted servers in Europe and the U.S. for multiplayer play.
A programmer has turned a classic test of persistence into a database showcase. Lukas Vogel built a Doom port that runs with the game’s rules and visuals driven by SQL statements stored in a database, with a light Python layer handling timing, input, and how frames are shown on screen.
The result is a curious blend of gaming and data engineering: 640×480 color frames surfaced from about 1,300 lines of SQL, spread across 89 query blocks. An earlier attempt, called DoomQL, used grayscale raycasting and looked more like Wolfenstein 3D than Doom, relying on a simpler rendering path that didn’t traverse the BSP tree Doom uses for depth and complexity.
Vogel describes the approach as deliberately awkward but functional: “Rendering Doom in a database is obviously a bad idea.” Still, the setup can run the full game loop and deliver frames by querying the database, which is the core trick here: the world layout and dynamic state are modeled inside the database while the Python wrapper feeds inputs and timing and then translates results into pixels on the screen.
In practice, the database holds the static world geometry and current game state, while the Python script handles user input, timing, and frame display. For players, that means Doom can be experienced from a database-backed stack, though this remains a tech demo rather than a practical re-release of the classic shooter.
01
What is SQLDoom and why does it matter?
SQLDoom is a proof-of-concept showing how flexible databases can be. It demonstrates that complex rendering and game logic can be expressed with SQL operations instead of traditional game-engine code. It’s not a call to replace engines, but a reminder that data systems can model real-time processes in unconventional ways.
02
Performance and practicality
On a laptop with a Ryzen 7 7840U chip, Vogel reports around 60 fps in calmer scenes, with frame rates dipping to about 35 fps in busy moments. The project uses roughly 1,300 lines of SQL code across many queries, while a separate script translates results into on-screen pixels. The takeaway isn’t a ready-to-play Doom port, but a striking demonstration of what you can accomplish when you push a database beyond storage toward computation.
03
How you can try it yourself
You can run the code locally with CedarDB and Doom’s original data files, or join hosted multiplayer servers reported by the project, with servers in Europe and the United States. It’s mainly a hands-on curiosity rather than a practical game release.
04
What this means for ordinary users
For most readers, SQLDoom isn’t a title you’d download to play routinely. It’s a demonstration of how adaptable modern databases can be and a reminder that developers keep finding new ways to model real-time processes using data systems.
The project will likely inspire more experiments that explore DB-backed rendering or new ways to express real-time tasks in SQL. If you’re curious, watch for updates from the developer on hardware scaling and potential future iterations.
06
Quick answers
What is SQLDoom?
It’s a Doom port where game state and visuals are driven by SQL queries inside a database, with a small Python layer for timing and output.
Why do this at all?
It’s a tech demo that shows how flexible databases can be and how rendering ideas can be expressed in database terms.
Can you play online?
Yes, there are public online multiplayer servers mentioned by the project, hosted in Europe and the U.S., though performance will vary.