Lukas Vogel stared at the original Doom code and saw tables. Not metaphorically. Actual relational tables.

The CedarDB engineer took the 1993 first-person shooter, loaded its level data into a database, then rewrote every piece of game logic and rendering as SQL queries. No C. No custom engine. Just queries. And it runs at 35 frames per second.

Short version: Doom now lives in CedarDB. The game loop fires 35 times a second. Each tick updates monster positions, handles collisions, tracks projectiles. All inside transactions. A thin Python client reads keyboard input, calls the queries, and paints the returned bitmap. That’s it.

The project, detailed in CedarDB’s own blog post, uses roughly 5,900 lines of SQL for logic and another 1,300 lines across 89 common table expressions for the renderer. The original Doom game logic sat around 9,000 lines of C. Vogel’s version is leaner. And stranger.

Doom’s .wad files map almost perfectly to relational structures. Vertices connect to linedefs. Linedefs bound sidedefs. Sidedefs reference sectors. Things sit inside those sectors. Vogel wrote about 1,000 lines of Python to import the shareware episode in roughly 18 seconds on his laptop. The binary space partitioning trees that John Carmack used for visibility became sortable columns with precomputed order keys.

But the renderer proved harder. Vogel’s earlier experiment, DoomQL, managed only simplified raycasting that produced grayscale, ASCII-like output reminiscent of Wolfenstein 3D. He wanted the real thing. Textures. Sprites. Arbitrary wall angles. Varying floor heights. The full 320×200 framebuffer.

One massive query paints every pixel.

The rendering query walks the BSP, determines visible surfaces, projects sprites, handles occlusion, draws the heads-up display. It returns a complete RGB bitmap. On an AMD Ryzen 7 7840U laptop, the system hits 60 frames per second in lighter scenes and holds around 35 fps during heavy combat. A typical tick with six monsters takes 2.15 milliseconds. Even a crowded E4M1 map with 46 active monsters stays under 11 milliseconds, well inside the 28.6-millisecond window needed for Doom’s original timing.

And. The database acts as single source of truth. Transactions guarantee consistent state. “With a database, there’s no partially applied updates, physics bugs, or disagreements over whether the rocket actually hit,” Vogel told Ars Technica. That atomicity eliminates entire classes of bugs that plague traditional game engines.

Multiplayer just worked. CedarDB handles concurrency. Four-player deathmatch servers run in Europe and the US. Players join public instances that rotate through Episode 1 maps every 10 minutes. When slots fill, newcomers queue. Or they open a SQL console and query the live match state directly. Because everything is data.

Vogel built this during parental leave. He couldn’t let the earlier DoomQL effort rest. That project from 2025 proved SQL could drive a multiplayer shooter but fell short on visuals. SQLDoom closes the gap. It loads real WAD data. It recreates the original engine’s feel. “I intended it as a tech demo, but it just feels like the real Doom, even though it doesn’t share a single line of code with any existing Doom port,” he said in the TechRadar coverage.

Database vendors have chased this kind of demonstration for years. DuckDB-Doom appeared earlier, using SQL views for raycasting. Vogel pushed further. He turned the entire simulation into queries. Bulk updates replace loops. One UPDATE statement can change every imp’s health or give the shotgun 500 pellets. Game balance becomes ad-hoc SQL.

Critics note the obvious. This isn’t portable to plain PostgreSQL or SQLite without major rewrites. It relies on CedarDB’s query compiler, which turns complex SQL into LLVM machine code, and some cedarscript extensions for timing. The overhead of constant table reads and writes is substantial. Yet the system still outperforms the simpler DoomQL on the same hardware.

So what? For database engineers, the project shows how far query optimizers have come. Complex table expressions that once crawled now fly. For game developers, it highlights the surprising fit between Doom’s original data-oriented design and relational models. Carmack’s tricks from 1993 translate into joins and sorts with little violence.

But the real draw sits in the sheer improbability. A game built for 386 processors now runs its core inside the same technology used for financial reporting and inventory systems. Players fire rockets at demons while the database maintains perfect consistency across every entity update.

Vogel open-sourced the code on GitHub. Anyone with CedarDB Community Edition, Python, and a legal Doom WAD can run it locally. Or jump into the public deathmatch servers. The instances accept new players regularly.

Recent coverage from Tom’s Hardware and Hackaday captured the community’s reaction. Engineers called it both cursed and wonderful. One X post summed it up neatly: the most cursed and wonderful port yet.

The project won’t replace traditional engines. Nobody plans to ship the next AAA title as 89 CTEs. Still, it forces a question. If Doom runs this well in SQL, what else might? And how many other programs hide data relationships that modern databases could exploit more aggressively than their original authors imagined.

Vogel already answered part of that question. He made it work. He made it fast enough to feel like Doom. And he did it with nothing but queries.