Developer Gets Doom Running Entirely Inside a SQL Database

A developer has built a working Doom SQL database port, turning the 1993 shooter into a playable game that runs entirely through live database queries instead of a traditional game engine. The project uses CedarDB, a modern analytical database, to calculate every frame, track every enemy, and even handle multiplayer sessions in real time.

It sounds like a joke until it is running on screen. Doom has long been the internet’s favourite benchmark for “can it run Doom” experiments, appearing on everything from pregnancy tests to ATMs and printers. This latest effort pushes that tradition somewhere stranger: a piece of software normally used to crunch spreadsheets and business records is now rendering a first-person shooter in full colour, frame by frame, through structured queries.

How the Doom SQL Database Port Actually Works

At its core, a database stores information in tables and answers questions about that information using queries. The Doom SQL database port takes that same structure and repurposes it to represent a game world. Map geometry, enemy positions, player health, and weapon states are all stored as rows in tables rather than variables in a game engine’s memory.

Each frame of gameplay is produced by running a query against that data, recalculating what has changed since the last frame and generating the pixels needed to display it. That includes lighting, sprite placement, and colour, none of which a conventional database is designed to output. Getting a query engine to produce a usable image at a playable frame rate, rather than just a table of numbers, is the genuinely difficult part of the project.

Game logic such as collision detection, enemy behaviour, and damage calculations is handled the same way, through queries rather than hand-written game code. Multiplayer works by letting multiple clients query and update the same shared database state concurrently, which is close to how many real-world business applications already handle simultaneous users, just repurposed for virtual demons instead of inventory records.

Why CedarDB Was the Right Tool for the Job

CedarDB is not a hobby project. It was built by a team including former Technical University of Munich researchers who have spent years working on high-performance query compilation, and it is pitched as a faster alternative to established systems for analytical workloads. That speed matters here, because a database designed to churn through millions of records per second is far better suited to generating dozens of frames per second than an older, slower system would be.

Running Doom through CedarDB effectively acts as a public stress test of the engine’s query compilation speed, done in a way that is instantly understandable to anyone, unlike a typical database benchmark full of abstract numbers. A viewer does not need to know anything about query planning to appreciate that a shooter is running smoothly inside something that was never meant to display graphics at all.

Doom Has Always Been the Internet’s Favourite Porting Target

This is far from the first time someone has decided that Doom belongs somewhere it clearly was not designed to run. Enthusiasts have previously squeezed it onto calculators, smart fridges, digital cameras, and even a pregnancy test with a tiny screen. The appeal is partly technical bragging rights and partly nostalgia, since the original game’s low system requirements and open file formats make it an unusually forgiving target for experimentation.

What sets the Doom SQL database port apart is that most of those earlier ports still rely on something resembling a conventional game loop underneath, even on strange hardware. Running the actual game logic and rendering through database queries is a different kind of challenge entirely, closer to asking a calculator to compose music than to simply shrinking a game onto a smaller screen.

What It Means Beyond the Novelty

Beyond the fun of seeing Doom run somewhere absurd, the project says something real about how capable modern query engines have become. Databases are typically judged on how fast they can sort, filter, and join data, not on whether they can hit a playable frame rate while rendering a 3D environment. Pulling that off suggests CedarDB’s query compilation is genuinely fast, not just fast relative to older database software.

For game preservation enthusiasts, it is also a reminder of how flexible Doom’s engine and file structure remain more than three decades after release, long after its original publisher moved on to other projects. For database engineers, it is a far more entertaining demo than another spreadsheet benchmark, and likely to be cited in presentations about query engine performance for years to come.

Frequently asked questions

What database is being used to run Doom?

The project uses CedarDB, a high-performance analytical database built by a team that includes former Technical University of Munich researchers, chosen for its fast query compilation.

Is the Doom SQL database port fully playable?

Yes. It supports full colour rendering, standard game logic such as combat and movement, and multiplayer sessions, all generated through live SQL queries rather than a conventional game engine.

Why do developers keep porting Doom to unusual platforms?

Doom’s low system requirements and openly documented file formats make it an easy target for experimentation, and successfully running it on unlikely hardware or software has become a well-known way for developers to demonstrate technical skill.

Does this mean databases could replace game engines?

Not realistically. The project is a demonstration of query engine speed and flexibility rather than a practical approach to game development, since purpose-built engines remain far more efficient for real games.