It is the oldest joke in software: if it has a processor, someone will eventually get Doom running on it. The shooter has been wedged into thermostats, printers, pregnancy tests, cash registers, and even a copy of Minecraft. Now a developer has done it inside something that was never designed to draw a single pixel — a relational database.

Lukas Vogel's project, dubbed SQLDoom, renders id Software's 1993 classic using CedarDB as its game engine, with the game's logic expressed almost entirely as SQL queries. The work was first documented in a lengthy blog post and has since been picked up by Ars Technica, Hackaday, MSN, and the developer forum GameDev.net, each framing the stunt a little differently.

How it works

Strictly speaking, the database does not run the whole game. A small Python client handles input and output, drives the game's timing, and blits each finished frame to the screen. Everything in between is SQL. A set of CedarDB tables tracks the game geometry and state — player position, level data, the world's walls and enemies — while roughly 1,300 lines of SQL, spread across 89 common table expressions, implement the game logic and produce the frames themselves.

The output is not a novelty ASCII sketch. SQLDoom generates full-color 640x480 bitmap framebuffers at 35 frames per second, a resolution and palette that would look at home in the original Doom executable. That throughput is the genuinely surprising part: a database is being asked to act as a per-frame rendering pipeline, and it is keeping up with a real-time game loop.

Rendering Doom in a database is obviously a bad idea.

That is Vogel's own assessment, quoted by Ars Technica, and it doubles as the project's mission statement. The point is not efficiency. The point is finding out where the boundary of a database actually lies — and then pushing past it.

From DoomQL to SQLDoom

SQLDoom is a sequel of sorts. Last year Vogel built DoomQL, described at the time as an attempt at a multiplayer Doom-like shooter written entirely in SQL. That effort stalled at raycast, grayscale ASCII graphics — technically impressive, visually closer to the flat, 90-degree angles of Wolfenstein 3D than to the pseudo-3D geometry of Doom.

The new version closes that gap. Where DoomQL proved a database could run a game loop, SQLDoom proves it can carry a color framebuffer, a substantially harder problem because every frame must be materialized as data before it can be drawn.

Different outlets, different angles

  • Ars Technica led with the engineering, walking readers through the Python client, the CedarDB schema, and the 89 CTEs, and treating SQLDoom as a measurable improvement on its predecessor.
  • Hackaday took a broader view, framing the story around the practice of abusing database engines — highlighting work with DuckDB-WASM, the WebAssembly build of the analytical database, as part of the same wave of experiments. Where Ars focused on one implementation, Hackaday treated SQL-as-a-game-engine as a genre.
  • MSN went for the punchline, headlining its aggregation simply: Doom ported to SQL — welcome to hell. The phrasing captures the tone much of the coverage has taken: admiration delivered with a knowing wink.
  • GameDev.net republished the story under the same headline as Ars, pushing it into the game-development community, where the reaction has been a mix of bafflement and appreciation for the query gymnastics involved.

The varied framing says something about how this kind of story travels. To a database or systems audience it is a demonstration of what modern analytical engines can be coerced into doing. To a gaming audience it is a curiosity. To a general audience it is a headline about hell.

The culture that keeps doing this

The Will it run Doom? tradition is older than most of the devices that have now run it, and it sits inside a wider culture of tinkering, reverse engineering, and interoperability that digital-rights advocates have long defended. The Electronic Frontier Foundation has consistently argued that users should be free to understand and repurpose the hardware and software they own, a position that has shaped debates over everything from jailbreaking to repair rights. Wikinews recently published an interview with the EFF's Danny O'Brien, a reminder that the impulse behind projects like SQLDoom — take a closed artifact, open it up, do something its creators never intended — is the same impulse that animates much of the policy work around user freedom.

Why it matters, sort of

Nobody is going to ship a commercial game as a database schema. The performance ceiling is real, and Vogel says as much himself. But the experiment is a stress test of abstractions developers rely on daily. Common table expressions, query planners, and bitmap handling are all being asked questions they were never asked before, and the answers are public.

There is also a quieter lesson about modern tooling. CedarDB, DuckDB-WASM, and their peers have become fast and expressive enough that a language designed for retrieving rows can plausibly stand in for a game loop. Thirty-five frames per second is not a benchmark anyone asked for. It is simply evidence that the boundary between data and code is blurrier than it used to be — and that somewhere, someone is already wondering whether Doom II fits.