SQLDoom draws full-color 640x480 frames from about 1,300 lines of SQL, supports online deathmatch, and shares no code with any earlier Doom port.
Developer Lukas Vogel has made Doom run entirely inside a SQL database. His project, SQLDoom, stores the maps and game state in CedarDB tables and uses about 1,300 lines of SQL to run the game and draw every full-color 640x480 frame. A small Python script only handles timing, controls and showing the image.
On a Ryzen 7 7840U laptop, it hits around 60 fps, dropping to 35 fps in busy fights. It's a big step up from Vogel's earlier DoomQL, which used gray text graphics.
It's a tech demo, not a new release. You can try it online or run it locally with CedarDB and your own Doom WAD files.
Doom now runs inside a database. Not on a server next to one, not with a database saving your progress, but with every wall, enemy and frame worked out by SQL queries, the language normally used to pull sales figures out of spreadsheets. Developer Lukas Vogel calls the project SQLDoom, and it plays at 35 to 60 frames per second.
Why should you care? Partly because it’s a great stunt in the long tradition of getting Doom to run on things that were never meant to run it. But it’s also a real test of how far modern databases have come. If a query engine can draw a 3D shooter in real time, it is a lot faster and more flexible than most people assume.
SQLDoom keeps the whole game inside tables in CedarDB, a database system that turns complex queries into machine code before running them. The level layout lives in one set of tables. The changing game state, such as where you are, where the monsters are and what has been shot, lives in others.
Every frame, the database runs its queries and produces the picture as a table of exact colors. A small Python script sits outside and does only three jobs: it keeps time, passes your key presses in and shows the finished frame on screen. Vogel set himself the rule that all rendering and the full game loop had to happen in SQL, with nothing but color tables or bitmaps coming out.
The logic adds up to roughly 1,300 lines of SQL spread across 89 query blocks known as common table expressions, which are named steps a query builds on one after another. The output is full-color 640×480 video. Vogel says none of its code comes from earlier Doom ports, yet it still feels like the real game.
This is actually Vogel’s second try. Last year he released DoomQL, which used raycasting, a simpler trick that fires imaginary lines out from the player to find walls. It drew the world with gray text characters and looked more like Wolfenstein 3D than Doom.
What it skipped was the BSP tree, short for binary space partitioning. It’s the clever map structure the original Doom engine uses to work out quickly which walls are in front of which. Doing it properly was the reason for a second version.
Walls turned out to be the easy bit. When a map loads, SQLDoom works out a sort key for each wall section, so a single ordering instruction tells the database what to draw first.
Floors and ceilings were much tougher. The original game paints them using visplanes, patches of flat surface tracked as the screen is drawn, along with lots of changes in state. Neither idea fits a system that renders one column of pixels at a time. Vogel’s fix, which he cheerfully calls “pretty hacky,” loops through a list of sorted panels to fill in those surfaces.
On a laptop with an AMD Ryzen 7 7840U chip, Vogel gets around 60 fps in quiet areas, falling to 35 fps when the action gets busy. That is playable by any standard, and it’s a big jump over DoomQL, even though he says the overhead of working through tables is heavy.
The online experience is a different story. SQLDoom supports deathmatch, and there are free public servers in Europe and the United States. People who tried those hosted demos found them sluggish, though at least one tester blamed the servers rather than the port itself. If you want to judge the real speed, run it on your own machine.
“Rendering Doom in a database is obviously a bad idea,” Vogel wrote in his blog post about the project. Then he made a case for it anyway.
His argument is about consistency. A database always holds one agreed version of the game state. Changes are applied completely or not at all, so you never get half-finished updates, odd physics glitches or arguments between players over whether a rocket really landed. Anyone who has rage-quit an online shooter over a hit that didn’t count will see the appeal.
The project also works as a showcase for CedarDB’s query compiler. And for engine programmers, the interest is less about shipping a database-powered shooter and more about what the experiment shows: how to represent game state as data, how to batch work, and how much of a real-time job can be handed to a system that you describe rather than program step by step.
Nobody is going to replace a game engine with SQL any time soon, and SQLDoom is a tech demo, not a re-release. The everyday lesson is about the software behind the apps you use. The same databases that track your bank balance, store orders and messages are now fast enough to draw a shooter frame by frame. That speed is part of why search boxes, dashboards and shopping sites keep getting snappier.
There are two ways to try it:
It’s a version of Doom where the game logic and the graphics are produced by SQL queries inside a CedarDB database, with a small Python script for timing, input and display.
Developer Lukas Vogel. It follows his earlier DoomQL project from last year, which used simpler raycast graphics in gray text.
Yes. There are public deathmatch servers in Europe and the United States, though testers found them slow. Running it locally gives a better picture of its speed.
You're reading the quick version.
Read next
PlayStation Pulse vs Pulse Elite: what the $50 cheaper model drops
Sony's new $99.99 PS5 headset is on preorder now and ships Nov. 19. It fixes the Elite's biggest flaw, but loses two handy extras. Here is how to choose.
The Good Guy leaves Dead by Daylight stores soon, and he is half price until then. Here is what you keep, what changes and why it keeps happening.
Rumors of a third delay keep spreading as rival games flee to 2027, but Rockstar's November 19 launch date hasn't moved. Here's what's official and what isn't.
FromSoftware has pushed its Switch 2 exclusive into next year without naming a day. Here's what the August test exposed and what the extra months are for.
The Daily Brief
Every morning, the news that matters from AI, phones, apps and the people shaping tech. Explained in plain English. Free.
One email a day. No spam, unsubscribe anytime. Privacy policy
