Someone got Doom in an SQL database

When Lukas Vogel announced he’d rendered the classic first‑person shooter Doom inside an SQL database, the tech world collectively rolled its eyes. “Rendering Doom in a database is obviously a bad idea,” he wrote, acknowledging the absurdity of the premise. Yet the ensuing project, dubbed SQLDoom, proved that “obviously” can be a matter of perspective. By marrying a modest Python client with a sprawling CedarDB schema, Vogel turned a relational engine into a game engine, delivering full‑color 640 × 480 frames at near‑real‑time speeds. The effort is more than a novelty; it illustrates how conventional data‑management tools can be repurposed for real‑time, interactive workloads.

From WAD to Table: Translating Doom’s Data Model

At the heart of Doom’s architecture lies a tidy decomposition of level geometry into vertices, linedefs, sectors and other primitives. Vogel leveraged that structure, loading the game’s classic WAD files into a series of CedarDB tables. The conversion was “relatively simple and straightforward,” because each WAD element maps cleanly onto a relational row. Even Doom’s binary‑space partition (BSP) trees—critical for determining visible surfaces—found a home in SQL via a pre‑computed sort_key column. By sorting on this key, a single ORDER BY clause could decide which walls to draw each frame, sidestepping the need for the original engine’s bespoke traversal logic.

This table‑centric representation did more than preserve the original level data; it gave the game a “steady reference snapshot” of its state. In a traditional game loop, mutable in‑memory structures can lead to inconsistencies when multiple players interact simultaneously. By persisting everything in a database, SQLDoom inherits the ACID guarantees of CedarDB, eliminating “partially applied updates, physics bugs, or disagreements over whether the rocket actually hit,” as Vogel notes. The result is a clean, deterministic foundation for multiplayer sessions—something the original Doom engine never natively offered.

The Python Wrapper: Bridging Input, Timing, and Display

SQLDoom does not rely on SQL alone to run the game. A lightweight Python client sits at the front end, handling user input, driving the game clock, and rendering each bitmap to the screen. This client reads the current frame buffer from the database, then pushes the pixel data to a window using standard graphics libraries. By offloading these real‑time responsibilities to Python, Vogel sidestepped the performance penalties of executing every frame entirely within SQL, while still keeping the core game logic inside the database.

The division of labor is pragmatic: Python excels at I/O and event handling, whereas SQL shines at bulk data manipulation and set‑based calculations. The Python layer issues a series of queries each tick, retrieves the resulting 35 bitmap framebuffers per second, and displays them. This hybrid approach allows the system to achieve “about 60 fps on a Ryzen 7‑powered laptop,” with occasional dips to “35 fps for busy scenes.” Those numbers, while modest compared to native Doom ports, are impressive given the overhead of constantly reading and writing to a relational store.

SQL Logic: 1,300 Lines, 89 CTEs, and 35 Framebuffers

The bulk of SQLDoom’s engine lives in a dense forest of Common Table Expressions (CTEs). Vogel assembled roughly 1,300 lines of SQL spread across 89 CTEs to implement everything from wall rendering to enemy AI. Each CTE builds on the previous, progressively shaping the scene for the current frame. The final output is a bitmap buffer that the Python client pulls and blits to the display.

Generating 35 bitmap framebuffers per second means the database is executing a full rendering pipeline roughly every 28 ms. That cadence is a testament to CedarDB’s query optimizer and the careful structuring of the CTE chain. By pre‑computing static data—like the BSP sort keys—and limiting per‑frame calculations to dynamic elements such as player position and monster movement, Vogel kept the query workload within a feasible envelope for a laptop‑class CPU.

Floor and Ceiling Rendering: A “Pretty Hacky” Workaround

One of the trickier aspects of porting Doom to SQL was handling floors and ceilings. The original engine uses “visplanes,” a clever column‑by‑column technique that updates rendering state as the player moves. SQL, being set‑oriented, lacks the mutable per‑column state that visplanes rely on. Vogel’s solution was to iterate over an ordered list of panels—a method he describes as “pretty hacky.”

While the hack sacrifices the elegance of visplane‑based rendering, it still produces visually accurate floors and ceilings. By ordering panels and processing them sequentially, the engine can determine which portions of a floor or ceiling are visible at any given angle. The approach is computationally heavier than the original method, but the database’s ability to handle large set operations mitigates the performance hit enough to keep frame rates respectable.

Multiplayer Potential: Databases as Game Servers

Beyond the novelty of playing Doom from a SQL query, Vogel highlights a more strategic advantage: using a database as the authoritative game server. Traditional multiplayer servers must juggle network latency, state synchronization, and conflict resolution. With a relational backend, the game state is inherently synchronized across all clients that query the same tables. The ACID properties guarantee that every player sees a consistent world, eliminating “disagreements over whether the rocket actually hit.”

Because the database already handles concurrency, scaling to multiple players becomes a matter of provisioning more database resources rather than rewriting networking code. In theory, any number of clients could connect to the same CedarDB instance, each issuing the same set of queries to retrieve the current frame buffer and submit input actions. The database would serialize those actions, apply them to the game state, and broadcast the updated frame buffers back to all participants.

Getting Started: From Code to Play

For those intrigued enough to try SQLDoom themselves, Vogel provides a straightforward path. The full source lives on GitHub, accompanied by a copy of CedarDB and instructions for loading a Doom WAD file. With those three components—a Python client, the CedarDB engine, and a WAD—the system can be compiled and run on a typical laptop. Vogel also offers a free online demo, though he notes “pretty poor performance” when accessing the hosted version, likely due to network latency and shared server resources.

The barrier to entry is low for developers familiar with SQL and Python, but the performance ceiling is bounded by the underlying hardware and database configuration. Running locally on a Ryzen 7 machine yields the best results, while cloud‑hosted instances may suffer from higher latency. Nonetheless, the project serves as a compelling proof‑of‑concept for repurposing relational databases as real‑time engines.

Why It Matters: Rethinking Databases in Real‑Time Applications

SQLDoom is more than a geeky side project; it challenges the conventional wisdom that databases are solely for CRUD‑style workloads. By demonstrating that a relational engine can drive a frame‑by‑frame rendering pipeline, Vogel forces the industry to reconsider the role of data stores in latency‑sensitive environments. The project also underscores the flexibility of modern SQL engines, which now support complex CTEs, window functions, and even procedural extensions that can approximate traditional programming constructs.

In an era where edge computing and real‑time analytics are becoming mainstream, the ability to embed game‑like logic directly into a database could open doors for collaborative simulations, shared virtual environments, and even secure multiplayer experiences that benefit from the database’s built‑in authentication and access controls. While SQLDoom itself may not replace native game engines, it serves as a vivid illustration of how existing infrastructure can be stretched into new territories—provided developers are willing to accept the trade‑offs and get a little “hacky” along the way.

This article was produced with AI-assisted research and editorial support. Reporting is based on the source material cited below. Sources: Ars Technica; arstechnica.com; Global1.News (03 October 2026).

By Jessica Ali, Staff Writer