SQLDoom: A SQL Database Now Renders Doom Pixel-Perfectly, BSP Tree and All

If you've ever wondered whether a database could run id Software's 1993 classic down to the exact rendering algorithm, someone has now answered that question twice, and the second answer is a lot more convincing than the first.

Back in 2025, database engineer Lukas Vogel built DOOMQL, a version of Doom's logic expressed in SQL. It worked, but the visuals landed closer to 3D Monster Maze than to the genre-defining shooter it was named after. The reason came down to rendering technique: Vogel used raycasting, a simpler method that casts a single ray per screen column to determine wall distances. It's fine for basic first-person visuals, but it's not what made the original Doom tick.

That distinction didn't go unnoticed. "Someone on Hacker News complained last year when I did the first iteration that that one was more Wolfenstein-like because I used raycasting instead of BSP-tree traversal, which was the thing that made Doom revolutionary," Vogel told The Register. "So I obviously couldn't let that stand."

Enter SQLDoom, a stricter and far more faithful port. This time the rules were tighter: the rendering had to be purely SQL-based, with "the only acceptable SQL output" being a table or bitmap encoding exact RGB values for every pixel. The game loop also had to run entirely in SQL. Python is still in the picture, but only for timing, keyboard input, and displaying the final bitmap. Everything else, including the binary space partitioning (BSP) tree traversal that Doom's original engine used to efficiently determine which surfaces are visible and in what order, now runs as database queries against CedarDB.

Why BSP Trees Matter Here

For anyone who hasn't touched game engine internals, BSP trees are worth a quick explanation. Doom's original renderer needed a way to draw a 3D scene from a 2D map without doing expensive per-pixel depth calculations. The solution was to precompute a tree structure that recursively splits the map into convex regions, letting the engine walk the tree at runtime and draw surfaces in back-to-front or front-to-back order without extra sorting. It's an elegant bit of 90s engineering, and it's precisely the part of Doom's architecture that raycasting-based clones like Wolfenstein 3D never had.

Getting that logic to run as SQL queries isn't trivial. You're essentially asking a declarative query language, designed for filtering and joining relational data, to do recursive tree traversal and per-pixel rasterization. Vogel pulled it off anyway, and according to him, performance actually improved over the cruder raycasting approach from the first iteration.

"I was very thrilled to find out that porting the real Doom was a) feasible and b) the performance was actually better than the much more barebones approach from last year," Vogel said. The explanation likely has less to do with SQL itself and more to do with CedarDB's architecture. CedarDB is a compiling database, meaning complex queries get compiled down to machine code rather than interpreted row by row. That compilation step is normally sold as a way to speed up analytical workloads. Here it's doing double duty as a game engine's render pipeline.

Vogel didn't stop at making it technically work. "At some point I started actually playing it for fun in my free time, which is still a very strange feeling," he said. "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. So I wanted to see how far I could take it. In the end, I even got deathmatch to work."

Deathmatch support means SQLDoom isn't just a single-player curiosity rendering static frames. It's handling multiplayer state, presumably tracking player positions, hits, and game state across sessions, all still expressed as SQL against a live database. That's a meaningfully harder engineering problem than rendering a single-player level, since it requires consistent, low-latency state updates rather than one-shot query execution.

On the hardware side, Vogel reports the game runs smoothly on his laptop, which packs an AMD Ryzen 7 7840U, a mobile chip that's solid but nowhere near a gaming rig's typical horsepower. Multiplayer matches are playable over EU and US servers, though The Register's own testing found server performance a bit sluggish, more likely a hosting issue than a fundamental limitation of the SQL approach.

It's also fair to call SQLDoom what it really is underneath the novelty: a demo built to show off CedarDB's query compilation chops. Running a 90s shooter entirely through database queries is a flashy way to prove that a compiling database engine can handle workloads well outside the usual OLAP or OLTP box. Whether that translates into practical use cases for CedarDB's actual customers is a separate question, but as marketing stunts go, it's a lot more compelling than another keynote demo of an online store checkout flow.

Key Takeaways

• SQLDoom replaces the raycasting approach of last year's DOOMQL with genuine BSP-tree traversal, the technique that made the original Doom's renderer distinct from simpler engines like Wolfenstein 3D.
• The rendering pipeline is strictly SQL-based, producing per-pixel RGB output as database query results, with Python limited to timing, input, and display duties.
• CedarDB's query compilation, normally pitched for analytical workloads, compiles the SQL render logic down to machine code, which Vogel says made SQLDoom faster than the earlier raycasting port.
• Deathmatch multiplayer works, running on EU and US servers, though The Register found server-side performance noticeably sluggish during testing.
• Underneath the novelty, SQLDoom doubles as a technical showcase for CedarDB, demonstrating that its compiling database architecture can handle workloads far outside typical query use cases.