Doom now runs in SQL, turning a relational database into a demon-slaying engine

Doom has already invaded pregnancy tests, smart fridges, and ancient home computers, so naturally the next frontier was the one place software engineers joke about more than they actually use for games: inside a relational database. Boing Boing flagged that milestone with a delightfully cursed project that ports id Software’s 1993 classic into SQL itself, turning standard database queries into a fully playable Doom clone running in CedarDB.

The project, dubbed SQLDoom, comes from CedarDB developer Lukas Vogel, who set out to move not just some toy logic but the original game’s core systems into SQL. According to coverage by The Register and CedarDB’s own technical write-up, Vogel implements both the game loop and the renderer as SQL queries executed inside CedarDB, with a thin layer of Python handling keyboard input, timing, and drawing the resulting bitmaps to the screen. Doom’s WAD data—levels, sprites, and other assets—is stored in tables, and each frame of gameplay is essentially the result of a massive SELECT operation that calculates the next game state and a full-screen image.

This is not a stripped-down proof-of-concept. CedarDB’s documentation and the SQLDoom GitHub repo describe a “more-or-less complete” port that includes WAD loading, BSP tree traversal, textured walls, enemies, weapons, and authentic Doom-level chaos. Spaziogames reports that the gameplay logic weighs in at roughly 5,900 lines of SQL, while the renderer adds another 1,300, numbers echoed in other international coverage of the project. Hackaday notes that the rendering path alone uses around 1,300 lines of SQL spread across 89 common table expressions, with roughly 4,000 more lines handling the rest of the work—numbers that put SQLDoom in the same ballpark of complexity as the original C code.

Under the hood, SQLDoom doubles as a stress test and showcase for CedarDB itself. CedarDB is a relational database that speaks the PostgreSQL wire protocol, which lets the project drive the game by sending queries as if it were talking to a standard Postgres server. The implementation leans on CedarDB’s own extension language, cedarscript, for some functions, but the maintainers point out that the code could be ported to PostgreSQL’s plpgsql, suggesting that Doom-on-SQL isn’t locked to one vendor. The Register emphasizes that Vogel imposed strict constraints on himself: the renderer had to be purely SQL, and the only acceptable output from the database was a table or a bitmap encoding exact RGB values for every pixel.

It’s also part of a wider wave of “can it run Doom?” experiments aimed squarely at the infrastructure geek crowd. Earlier this year, developers at Turso demonstrated a Doom example that runs inside SQLite’s virtual database engine (VDBE) bytecode, compiling SQL queries down to a tiny machine language and then using that to drive the game. Where Turso’s demo rides on the bytecode-level execution model, SQLDoom goes a step further by insisting on working at the SQL layer itself, making the language of joins, aggregates, and ORDER BY clauses do all the heavy lifting for world simulation and rendering.

The CedarDB team and outside write-ups single out the renderer as the most mind-bending part of the project. According to Spaziogames, SQLDoom re-creates Doom’s space-partitioning approach by representing BSP tree paths numerically and letting a SELECT with ORDER BY sort walls from nearest to farthest before drawing them. The GitHub README adds that the port supports smooth 60 FPS graphics, sound, and even multiplayer, all driven by the database’s query engine while Python simply blits the finished frames and plays audio. In other words, the system doesn’t just track player health and demon positions in tables—it uses SQL itself to decide exactly what pixels appear on screen every frame.

For database nerds and Doom lifers alike, SQLDoom is less about practical application and more about proving a point. Writing a high-performance renderer in SQL is wildly inefficient compared to a modern engine, but it highlights how flexible relational systems can be when you treat them as general-purpose compute platforms rather than just CRUD backends. It also extends the long-running joke that any new hardware or software stack must eventually answer the question “but can it run Doom?”; with SQLDoom, one more unlikely piece of technology has joined the club—and this time, the demons and chainsaws are literally powered by SELECT statements.