Original Doom's game logic and renderer rebuilt to run entirely as SQL queries

The original 1993 Doom has been ported to SQL, with both its game logic and its renderer executing as queries inside a database rather than as compiled game code. According to the CedarDB blog post behind the project, the game loop runs at Doom's native rate of 35 tics per second, and the renderer produces the full 320x200 frame buffer at up to 60 Hz on the author's laptop, an AMD Ryzen 7 7840U. A small Python client handles only timing, keyboard input and displaying the bitmap it receives back. Multiplayer deathmatch works as well.

The write-up, dated September 22, 2026 and titled SQLDoom, has since reached the front page of Hacker News. The author is hosting live deathmatch servers in the EU and US with four player slots each, running the shareware version of the first episode. When every seat is taken, visitors land in a queue, and if the queue is also full they can still connect and query the live game state directly via SQL.

A sequel to an ASCII prototype

Last year the same author released DOOMQL, a project that rendered ASCII-art frames resembling Doom at around 30 FPS. As the post concedes, commenters correctly noted it was much closer to Wolfenstein 3D than Doom, because it used a raycasting approach. The real Doom engine relies on BSP trees, which make correct depth ordering cheap enough to afford textures, walls at arbitrary angles and varying floor heights. The new port was built to close that fidelity gap, with the author noting the work was done during another stretch of parental leave.

Self-imposed rules

The port follows a set of constraints laid out in the post. It should look like the real Doom and, just as importantly, feel like it to play. The rendering must be purely SQL-based, with the only acceptable output being a table or a bitmap encoding exact RGB values for every pixel. The game loop must also be pure SQL, though user-defined functions inside the database are permitted. A client written in another language is allowed, but only to parse input, drive the game tics and display the resulting bitmap.

How it fits together

On the client side, a deliberately boring Python script built on pygame triggers a game tic 35 times per second, reads the keyboard and draws the frame it gets back. Everything else — game logic, game state and the renderer — lives inside the database. The two paths are intentionally separate: logic advances at a fixed 35 Hz, while the renderer is a pure function of the game state tables, so the client can request a fresh frame as often and as fast as it wants.

The game's data format helped the effort. Doom's WAD file format maps naturally onto relational structures: two vertex records are connected by a linedef, a linedef carries two sidedefs, sidedefs bound sectors, and sectors contain things. Translating a whole WAD into the database took roughly 1,000 lines of Python, and importing all of Doom 1 takes about 18 seconds on the author's laptop. As a demonstration, the post shows a single query that renders E1M1 as a bird's-eye-view ASCII map straight from those tables.

Why it matters

This is partly the latest entry in the long-running tradition of running Doom on improbable platforms, but it also serves as a genuine stress test of SQL's expressive range. A real-time game simulation with a software renderer is about as far from typical database workloads as it gets, and the project shows relational queries and user-defined functions can carry that load at the original game's speed. The architecture also illustrates a clean separation — game state lives in queryable tables, and rendering is a pure function of that state. That design is what enables the project's neatest trick: because a running match is just rows in a database, anyone can inspect it with ordinary SQL, which is exactly what spectators stuck in the server queue are invited to do.