"Doom Now Runs Inside a SQL Database — and It Makes a Strange Kind of Sense"

"Can it run Doom?" has become the internet's favorite way to test whether a machine has a soul. The 1993 shooter has been coaxed onto calculators, printers, earbuds, and — in a genuinely cursed experiment — a colony of gut bacteria. The newest entry in that lineage may be the most on-the-nose of all: Lukas Vogel has gotten Doom running inside a SQL database, rendering full-color, 640×480 frames of Hell out of nothing but tables and queries.

Before the joke lands too hard, it's worth being precise about what "Doom in a database" actually means. Vogel's project, SQLDoom, doesn't type a wall of SELECT statements into a psql prompt and hope for the best. A slim Python client handles the parts SQL was never meant to touch — input, timing, and blitting each frame to the screen. Behind that, a set of CedarDB tables holds the game's geometry and running state, while roughly 1,300 lines of SQL spread across 89 common table expressions carry out the game logic and churn out about 35 framebuffers per second. On a Ryzen 7 laptop it hits around 60 fps, dipping in busy scenes.

That's a substantial leap from Vogel's earlier attempt, DoomQL, which managed only grayscale ASCII graphics and raycasting so crude it looked closer to Wolfenstein 3D's blocky corridors than the real thing. The new version produces frames that could pass for the original executable, and that jump is the interesting part: it happened because Vogel figured out where Doom's data model and a relational schema naturally align.

Doom's WAD files turn out to be surprisingly database-friendly. The engine already decomposes every level into vertices, lines, sectors, and other primitives — exactly the kind of normalized records a table wants. Even Doom's famous binary-space partition trees, the culling trick that decides which walls you can see, translate cleanly into SQL: Vogel pre-computes a sort_key for every object at load time, then lets a plain ORDER BY statement figure out each frame which surfaces to draw and which to discard.

That translation is possible for a reason worth naming directly: SQL with recursive common table expressions is Turing complete. Give a query engine the ability to recurse and branch and it can, in principle, compute anything a general-purpose machine can. "Can it run Doom?" has always been a disguised question about computational universality — whether a system is a calculator or a computer — and a database with CTEs clears that bar the same way a printer's web interface or a TI-83 does.

The floor and ceiling rendering is where the mapping breaks down, and it's the most instructive failure in the project. The original game uses a "visplane" algorithm with state mutations that step column by column — an imperative loop that has no natural expression in declarative SQL. Vogel's answer is what he cheerfully calls a "pretty hacky" substitution that iterates over an ordered list of panels. Watching a talented engineer shim an imperative algorithm into a declarative language is a clean reminder that paradigms are not interchangeable; some ideas translate, others get bolted on.

There's a second-order insight here that matters more than the rendering. Vogel points out that a database's persistent "reference snapshot" of game state, plus its built-in concurrency and access handling, is genuinely useful for running a multiplayer server: no partially applied updates, no physics bugs, no disagreement between clients over whether a rocket actually landed. That's not a gag. A system built for ACID transactions and concurrent writes happens to solve a real class of netcode synchronization headaches, which is why "authoritative state in a database" is a pattern that shows up in real production systems, not just novelty ports.

It also mirrors a broader trend in the data world that's easy to miss from the outside. For years the industry has been pushing computation toward data — in-database analytics, query engines like DuckDB, Postgres extensions that run ML inside the engine — rather than hauling data out to some separate application. SQLDoom is the same idea pushed to its absurd conclusion: if a database can do the compute, why not have it compute an entire first-person shooter? It's a joke that happens to point at a real architectural shift.

So why Doom, specifically, out of every game ever made? A big part of the answer is id Software's 1997 decision to release the Doom source code, which turned the engine into public property that anyone could port, bend, and abuse. Combined with an engine that was famously lean and portable even by mid-90s standards, Doom became the default benchmark — the "Hello, World" of "does this machine actually compute."

That status is what keeps the meme alive two decades after it should have worn out. Nobody ports Doom to a SQL database because it's useful; they do it because it's a proof, a puzzle, and a small act of defiance against the assumption that a tool can only ever do the one job it was designed for. The constraint is the point, and the community around these ports treats each new one the way a makerspace treats a beautifully impractical invention.

If you want to see it for yourself, the whole thing is open: the SQLDoom repo is on GitHub, and you can run it locally with a copy of CedarDB and a Doom WAD file, or jump into the free hosted demo without any setup at all.

The lasting takeaway isn't really about Doom, or even about SQL. It's that the line between "a database" and "a computer" is thinner than the job titles suggest. When the system you use every day to store rows turns out to be capable of rendering a demon-filled corridor at 60 frames a second, it's a useful nudge to stop treating your tools as fixed-function and start asking what they could do if you pushed them past the label on the box.

Further reading: Ars Technica's Kyle Orland has a full write-up of SQLDoom, and the same outlet's archive of unlikely Doom ports — gut bacteria, a pair of earbuds, and a CAPTCHA — is worth an afternoon of your time.