Doom Now Runs Inside an SQL Database, Rendered by Pure Queries

Doom has now landed somewhere few people expected: inside an SQL database. A developer has built a version of the 1993 shooter in roughly 1,300 lines of SQL, with the queries themselves producing bitmapped views of the game world.

The reported frame rate is 35 fps. That matches the original game's own cap, which was also 35 frames per second. For a language designed to fetch and filter rows rather than draw pixels, that is a notable result.

The project follows a long tradition of porting Doom to unlikely hardware and software. Over the years the game has turned up on calculators, printers, ATMs and even pregnancy tests. Those ports mostly show off a device's quirks. This one is different because the target is a query language, not a machine.

In practice, the work means expressing the steps of a classic 3D engine as set-based operations. Geometry, visibility and rendering are handled by queries rather than by loops and mutable state. Each frame becomes the output of a query that returns the colour values for the screen. SQL is declarative and has no native concept of drawing, so the engine has to be recast as data transformations.

Don't expect anyone to ship a game this way. Database engines are built for storage and analysis, not real-time graphics, and a project like this is an exercise in pushing a tool far past its intended use. But exercises like this tend to teach something. They show how capable modern SQL engines are, with their joins, recursive queries and window functions, and how much computation can be pushed into a single declarative statement.

As with most Doom ports, the appeal comes from the question of whether it can be done at all. The answer here is yes, and at the speed the original ran.