Glonce

SQLDoom renders Doom with SQL queries in a CedarDB database

miscThe Glonce editorsArs Technica🔥43Glonce rating43Impact20Novelty50Relevance65Surprise40Players15Credibility78
SQLDoom renders Doom with SQL queries in a CedarDB database

Lukas Vogel has written a lengthy blog post explaining how he rendered Doom using an SQL database. His own verdict, quoted by Ars Technica, is that "Rendering Doom in a database is obviously a bad idea." The article then adds a caveat to the headline claim: the SQLDoom project is not purely SQL. A small Python client handles input and output, drives the game's timing, and displays each frame on screen.

Behind that client, a series of CedarDB tables tracks the game geometry and state. About 1,300 lines of SQL queries, spread across 89 common table expressions, implement the game logic and generate 35 bitmap framebuffers per second. The frames are full-color and 640×480, and the article says they look like they could have come from the original Doom executable.

SQLDoom follows Vogel's earlier DoomQL project, which last year set out to build "a multiplayer Doom-like shooter entirely in SQL." That effort ended up with raycasting-based, grayscale ASCII graphics, closer to the simplistic 90-degree-angled maps of Wolfenstein 3D. The article calls the newer SQLDoom a major improvement.

The data side turned out to be the easy part. Converting Doom's classic WAD files to a relational database was relatively simple and straightforward, Vogel writes, because the original game broke levels down into vertices, lines, sectors and so on. Even Doom's famous binary-space partition trees can be broken down into SQL. The trick is a sort_key for objects, pre-computed for each position at load time. With that set in the table, a simple ORDER BY statement can decide every frame which parts of walls to display and which to ignore, which vastly improves performance.

Key facts

  • Lukas Vogel's SQLDoom renders Doom using CedarDB tables for game geometry and state, plus a small Python client for input, output, timing and displaying each frame.
  • About 1,300 lines of SQL across 89 common table expressions implement the game logic and generate 35 bitmap framebuffers per second.
  • Output is full-color 640×480 frames, a step up from Vogel's DoomQL project last year, which produced raycasting-based, grayscale ASCII graphics.
  • Doom's WAD files map easily to relational tables because levels are built from vertices, lines and sectors.
  • A sort_key pre-computed per position at load time lets an ORDER BY statement handle the binary-space partition trees and decide which wall parts to draw each frame.

Why it matters

This is a stunt, and Vogel says so himself: rendering Doom in a database is, in his words, obviously a bad idea. The interest is in how far a relational database can be pushed. SQLDoom goes well beyond his DoomQL project from last year, which managed only raycasting-based, grayscale ASCII graphics. The newer version produces full-color 640×480 frames at 35 framebuffers per second, all from SQL queries.

Who it affects

Mostly Doom tinkerers and database enthusiasts who enjoy seeing one tool bent into a very different job. The article presents it as a curiosity and does not frame it as something for production database work.

How to use it

There is nothing to deploy here; the article describes how the project is built. A Python client handles input and output, game timing and display. CedarDB tables hold the converted WAD data (vertices, lines, sectors and so on). About 1,300 lines of SQL in 89 common table expressions run the logic and draw each frame. The visible text does not say whether the code is open source or available to download.

How solid is it

The facts come from Ars Technica's summary of Vogel's own blog post, so the figures (about 1,300 lines of SQL, 89 common table expressions, 35 framebuffers per second, 640×480 frames) are the author's as relayed by the article. No hardware or benchmark conditions are given for the 35 framebuffers per second figure, and the article does not say whether that is an average or a peak.

Risks and caveats

The headline claim needs the article's own qualifier: the project is not entirely SQL, because the Python client does input, output, timing and display. The 35 per second rate comes with no stated test conditions. Vogel himself calls the whole idea a bad one, so treat it as a technical showpiece rather than a recommended way to build a game.

“Rendering Doom in a database is obviously a bad idea”

— Lukas Vogel, in his blog post on SQLDoom