Executive Overview
For over three decades, id Software’s Doom has served as the ultimate canvas for computational absurdity. If a device possesses a screen, a processor, and a power source, someone, somewhere, will inevitably figure out how to run the iconic 1993 first-person shooter on it. Enthusiasts have ported the game to digital cameras, ATM machines, pregnancy tests, and oscilloscope displays. Yet, the latest hardware stunt transcends simple device hacking. It pushes the boundaries of software engineering architecture by targeting a platform that was never designed to compute real-time graphics: a relational database management system.
In a technical tour de force that bridges the gap between database theory and retro gaming, software engineer Lukas Vogel has successfully rendered full-color, high-frame-rate Doom frames entirely through Structured Query Language (SQL). The project, appropriately dubbed SQLDoom, is documented in a comprehensive technical blog post and hosted as an open-source repository on GitHub.
“Rendering Doom in a database is obviously a bad idea,” Vogel admits with a blend of self-deprecation and engineering pride. Yet, behind the tongue-in-cheek premise lies a serious, rigorous exploration of modern database performance, query optimization, and the surprising expressive power of relational algebra.
Far from being a sluggish slide-show, SQLDoom pumps out a staggering 35 full-color, 640×480 bitmap framebuffers per second. It accomplishes this feat by leveraging CedarDB—a high-performance, vectorized relational database management system—running approximately 1,300 lines of complex SQL queries distributed across 89 common table expressions (CTEs).
This article provides an exhaustive examination of the SQLDoom project. We will trace its evolutionary lineage from early ASCII-based prototypes, analyze the structural mechanics of mapping a classic video game engine into relational tables, examine the performance metrics that make real-time database rendering possible, and explore what this eccentric experiment means for the future of database engine design.
Detailed Chronology: From ASCII Experiments to Relational Realism
The genesis of SQLDoom did not happen overnight. It represents the iterative culmination of an ongoing quest by Vogel to test the absolute limits of relational database capabilities. To understand the architectural leap represented by SQLDoom, one must look back at its predecessor, DoomQL, which laid the groundwork for this year’s technical breakthroughs.
The Prototype: DoomQL and the Limitations of ASCII
Last year, Vogel captured the attention of the systems engineering community with DoomQL—an ambitious project that sought to build a multiplayer, Doom-style shooter running entirely inside an SQL environment. While DoomQL successfully proved that game loops could theoretically be driven by database queries, the technical compromises required to achieve acceptable performance were severe.
DoomQL relied on raycasting algorithms executed inside SQL to generate grayscale, ASCII-based graphics. The visual output was stark, minimalist, and deeply nostalgic, bearing a closer resemblance to the grid-locked, 90-degree-angled corridor layouts of Wolfenstein 3D than the sweeping, non-Euclidean sector geometry of Doom. Furthermore, the rendering pipeline struggled with frame rates and resolution limits, bogged down by the sheer computational overhead of performing raycasting calculations inside a relational query framework without specialized spatial indexing optimization.
Although DoomQL was a functional proof-of-concept, it left Vogel unsatisfied. The graphics lacked fidelity, the performance lacked punch, and the core question remained unanswered: Could a relational database handle the complex spatial geometry, texture mapping, and high-frequency state management required to render genuine Doom frames at modern retro-gaming speeds?
The Birth of SQLDoom
Spurred by the bottlenecks of DoomQL, Vogel returned to the drawing board with a different philosophy. Instead of forcing the database to perform brute-force raycasting for every single pixel on the fly, he needed to leverage the structural strengths of a modern, vectorized database engine—specifically CedarDB—while rethinking how spatial data is organized and queried.
The development of SQLDoom required a hybrid architecture. While the database engine shoulders the monumental task of computing game logic, visibility culling, and frame generation, a lightweight Python client acts as the bridge between the physical world and the database server.
- Input Handling: The Python client captures keystrokes from the user (movement, firing, opening doors).
- State Updates: These inputs are transmitted to CedarDB to update the player’s positional coordinates and state vectors within the database tables.
- Execution: CedarDB executes the massive array of SQL queries, processing the relational state of the game world.
- Output Generation: The database outputs raw bitmap framebuffers at a rate of 35 frames per second.
- Display: The Python client reads these framebuffers and paints them onto the user’s physical monitor.
By dividing labor in this manner—offloading hardware I/O and timing synchronization to a thin client while keeping all computational heavy lifting strictly within the relational engine—Vogel unlocked a quantum leap in performance and visual fidelity.
Supporting Context & Metrics: Under the Hood of SQLDoom
To appreciate the engineering marvel of SQLDoom, one must examine how classic game architecture maps onto relational database theory. At its core, Doom is an aggregation of data: vertices, lines, sectors, things, and flats. Transforming these classic WAD files into a relational database was, structurally speaking, a surprisingly natural transition.
Translating WAD Files to Relational Schema
In the original Doom engine, levels are constructed using a hierarchical structure defined in the game’s WAD files. A level consists of:
- Vertices: 2D coordinate points in the game world.
- Lines (Linedefs): Connections between vertices that form walls, boundaries, and interactive triggers.
- Sectors: Closed polygons defined by linedefs that represent distinct rooms or areas, complete with floor and ceiling heights, and lighting values.
Vogel discovered that translating these geometric assets into relational tables was remarkably straightforward. Because relational databases are fundamentally designed to manage structured collections of entities and their relationships, a Doom map can be cleanly represented as a set of normalized tables: vertices, linedefs, sectors, and things.
However, representing static geometry is only half the battle. The true challenge of rendering a 3D environment in real-time is visibility determination—figuring out which walls are visible from the player’s perspective and which are occluded by other geometry.
Overcoming Occlusion: The Power of Pre-Computed BSP Trees
In traditional game engines, rendering performance relies heavily on Binary Space Partitioning (BSP) trees. Doom famously pioneered the use of BSP trees to quickly sort map geometry from back-to-front, allowing the renderer to draw walls without wasting cycles on objects hidden behind other structures.
Replicating this behavior inside SQL seemed, at first glance, like a performance nightmare. Executing complex recursive tree traversals dynamically within standard SQL queries generally destroys query execution speed.
Vogel solved this bottleneck with a brilliant pre-computation strategy. During the level-loading phase, before a single frame is rendered, CedarDB pre-computes a sort_key for every object and map surface based on its spatial position relative to potential viewing angles.
Once these sort keys are established in the table schema, the database no longer needs to perform complex, dynamic spatial calculations during gameplay. Instead, a simple ORDER BY clause in the SQL query handles the heavy lifting. By sorting the geometry based on the pre-computed keys, the database instantly determines which parts of walls to display and which to ignore. This optimization dramatically reduces query execution times, elevating performance from a sluggish crawl to a blistering 35 frames per second.
The Anatomy of the Query Pipeline
To generate a single 640×480 frame, SQLDoom executes a staggering collection of relational operations. The implementation relies on:
- ~1,300 lines of SQL code.
- 89 Common Table Expressions (CTEs). CTEs act as temporary result sets that exist within the execution scope of a single query, allowing complex multi-step transformations to be chained together cleanly.
- Vectorized Processing: CedarDB’s underlying architecture processes columns of data in vectors rather than operating on single rows sequentially, maximizing CPU cache efficiency and parallel execution across multiple cores.
Official Statements and Technical Insights
In his detailed technical documentation, Lukas Vogel expands upon the philosophical and practical implications of running a game engine inside a database management system.
“Rendering Doom in a database is obviously a bad idea,” Vogel writes in his blog post detailing the project. “Yet, it serves as an extraordinary stress test for query optimizers, memory management systems, and relational algebra execution pipelines. If a database can maintain a consistent 35 frames per second while processing complex spatial joins, occlusion culling, and state updates across nearly a hundred CTEs, it proves that modern database engines are capable of astonishing computational throughput.”
Database architects and systems engineers have taken note of the project’s implications. While running Doom in SQL will not replace traditional graphics pipelines for commercial game development, the underlying stress tests provide valuable telemetry for database developers.
Performance engineers at CedarDB noted that projects like SQLDoom push database engines into edge-case execution patterns that standard enterprise workloads rarely touch. By analyzing how CedarDB handles high-frequency transactional updates paired with massive analytical table scans—all executed simultaneously within short time budgets—engineers gain actionable insights into query optimizer bottlenecks, memory allocation patterns, and vectorization efficiency.
Future Outlook: What’s Next for Relational Gaming?
As SQLDoom captures the imagination of the developer community, questions naturally arise regarding the future of unorthodox computing experiments. Can relational databases be pushed even further into the realm of real-time simulation and interactive media?
Potential Extensions and Challenges
- Multiplayer Capabilities: Building upon the multi-user aspirations of the earlier DoomQL project, future iterations could theoretically leverage database row-level locking and ACID transactions to synchronize multiplayer deathmatch sessions directly inside a shared database instance, utilizing the database’s native concurrency control mechanisms to handle player collisions and netcode state.
- Raytracing and Modern Engines: While SQLDoom successfully mimics the classic software rendering pipeline of 1993 Doom, more advanced engines—such as those utilizing modern raytracing or voxel-based global illumination—would require an exponential increase in relational complexity. However, as GPU-accelerated databases continue to evolve, the boundary between relational data processing and real-time graphics rendering will continue to blur.
- Educational and Benchmarking Tools: Beyond mere entertainment, projects like SQLDoom demonstrate the untapped pedagogical value of unconventional benchmarks. Computer science educators are increasingly utilizing such projects to teach students advanced database indexing, query optimization, and spatial data structures in a highly engaging, gamified format.
Conclusion
Lukas Vogel’s SQLDoom is much more than a clever internet novelty or a tribute to a beloved 90s classic. It is a testament to the staggering flexibility and raw computational power of modern database engineering. By compressing game geometry into relational tables, harnessing pre-computed spatial sorting, and orchestrating 89 common table expressions at 35 frames per second, SQLDoom proves that with enough engineering ingenuity, virtually any computational environment can become a platform for Doom.
As long as engineers possess curiosity, coffee, and a compiler, one immutable truth remains absolute: It runs Doom.
