From Database Queries to Demon Slaying: How Engineers Ported DOOM to SQL

In the vast ecosystem of computer programming, Structured Query Language (SQL) is often relegated to the background. To the average layperson, it is a utilitarian instrument—a way to extract rows from a spreadsheet or manage the backend of a website. However, at its core, SQL is a Turing-complete programming language, possessing the logical capacity to perform complex computational tasks.

In a staggering demonstration of technical prowess, a team of engineers at CedarDB has pushed the boundaries of this language by successfully porting the seminal 1993 first-person shooter DOOM to run entirely on SQL. This project, which blends database management with retro-gaming, challenges our fundamental understanding of what a database engine can achieve.

The Genesis of an Impossible Project

The project began as an intellectual exercise to test the limits of CedarDB’s SQL implementation. While general-purpose languages like C, Python, or Rust are optimized for real-time rendering and input handling, SQL is designed for set-based operations. The challenge was not just to run the game, but to force a language built for data retrieval to perform the frame-by-frame calculations required for a 3D environment.

Chronology of the Development

1. Conceptualization (Q1 2024): The team identified the structural similarities between DOOM’s "WAD" (Where’s All Data) files and relational database tables.
2. Data Normalization (Q2 2024): The team spent months decomposing the WAD files—which contain textures, maps, and sound data—into a series of structured tables.
3. Rendering Engine Development (Q3 2024): The team focused on the "BSP" (Binary Space Partitioning) tree, the core of DOOM’s spatial navigation. They utilized Common Table Expressions (CTEs) to recursively traverse these trees within SQL.
4. Integration (Q4 2024): The team implemented a thin Python wrapper to handle keyboard interrupts and bitmap display, while the "game logic"—the movement, the firing, and the line-of-sight calculations—remained trapped inside the database engine.
5. Final Optimization (Early 2025): The final polish saw the reduction of the rendering logic to 1,300 lines of SQL across 89 massive CTEs.

The Architecture of a Database Shooter

To understand why DOOM functions inside a database, one must understand the architecture of the game itself. DOOM is famously not a "true" 3D game; it utilizes a 2.5D engine that relies heavily on 2D line segments and sector heights.

Leveraging CTEs for 3D Projection

The most complex hurdle was rendering. SQL is not designed to output a pixel stream; it is designed to return tabular data. To overcome this, the engineers utilized 89 Common Table Expressions (CTEs). A CTE acts as a temporary result set, allowing for complex, multi-step queries that can store intermediate states of the game’s geometry. By chaining these CTEs, the team effectively created a "pipeline" that simulates a vertex shader, transforming raw map coordinates into a 2D view on the screen.

Supporting Data: The Scale of the Build

The project is a testament to the verbosity of SQL. While a C++ version of the same engine might be concise, the SQL port comprises:

• 1,300 lines of SQL dedicated solely to rendering processes.
• 4,000 lines of SQL for game logic, movement, and entity management.
• 89 CTEs operating in tandem to simulate the game’s frame-by-frame logic.
• 35 FPS: The target frame rate, which the team managed to maintain by strictly indexing the database for rapid coordinate lookups.

The "Perfect Storm": Why SQL and DOOM Collide

There is a strange, almost poetic synergy between DOOM and SQL. Because DOOM’s original creator, John Carmack, had to implement a variety of mathematical "hacks" to get the game to run on early 90s hardware, the game is heavily reliant on linear algebra and data transformations—tasks for which SQL is uniquely suited.

In many ways, the "DOOM Engine" behaves like a query processor. It takes a player’s position (the query), filters the world geometry (the table), and renders only what is visible (the result set). The CedarDB team noted that the original engine’s reliance on look-up tables for trigonometry and distance calculations mirrored the way a database engine might cache frequently accessed data.

Official Responses and Industry Reception

The release of the project on GitHub sent ripples through the software engineering community. "This is the kind of project that reminds us why we get into computing," said one database architect on a public forum. "It’s not about practicality; it’s about proving that the tools we use every day have depths we haven’t even begun to explore."

The CedarDB team has remained humble, framing the project as a "labor of love" and a stress test for their database’s performance. In an official blog post, the team highlighted that the project was made possible because their database engine allows for high-performance, non-standard recursive queries, which are essential for navigating the complex data structures of the original DOOM maps.

However, the project has also drawn critics who argue that "Turing Tarpits"—the practice of forcing a language to do things it was never meant to do—can distract from legitimate software development. Yet, the consensus remains that such experiments provide invaluable data on the efficiency of recursive query execution, potentially leading to better database optimization strategies for real-world business applications.

Broader Implications: Beyond Gaming

What does it mean for the future of SQL? While no company is planning to move their gaming backend to a SQL server, the implications for data processing are significant.

1. Advanced Query Optimization

The techniques used to render DOOM—specifically the deep chaining of CTEs and recursive tree traversal—are directly applicable to complex data science tasks. By pushing the boundaries of what these queries can handle, developers are discovering new ways to optimize pathfinding and spatial analysis within standard databases.

2. The Limits of Turing Completeness

The project serves as a definitive case study in the power of Turing-complete languages. It proves that given enough patience and memory, virtually any computation can be expressed in SQL. This provides a philosophical bridge between database administration and software engineering, suggesting that the two fields are far more interconnected than they appear.

3. A Trend of "Impossible" Ports

This project sits within a growing cultural trend of porting DOOM to increasingly bizarre platforms. From Microsoft Word to Regular Expressions, developers are using the game as a benchmark for computational absurdity. These projects are not just memes; they are rigorous tests of the "computational environment" of the host platform.

Conclusion: A New Frontier for Databases

As we look toward the future of data management, the CedarDB DOOM project stands as a monument to human ingenuity. It forces us to reconsider the static nature of SQL and realize that, beneath the veneer of simple select statements, lies a powerful, logical engine capable of generating entire worlds.

Whether this leads to practical innovations in database rendering or remains a singular feat of engineering brilliance, it has succeeded in its primary goal: it has made the world look at the database engine with fresh eyes. For those interested in exploring the codebase, the project is hosted on GitHub, inviting developers to examine the 5,000+ lines of SQL that brought the Cyberdemon into the world of relational algebra.

In the final analysis, the project is a reminder that in the world of computing, the only true limit to what a tool can do is the imagination of the programmer using it. While you probably shouldn’t replace your GPU with a SQL database, the fact that you could is a triumph of modern engineering.