Although SQL is widely regarded as a tool for managing large datasets, it is essentially a programming language with features found in general-purpose languages such as C or Python. While it was not designed for general-purpose use, it can perform unexpected tasks. To demonstrate this capability, the CedarDB team ported the original DOOM to SQL. The WAD data—that is, almost everything outside the engine—was stored in tables. Maintaining the game’s 35 fps and rendering the images was more difficult: the rendering section consists of 1300 lines of SQL spread across 89 common table expressions (CTEs). The rest of the project uses 4000 lines of SQL, along with some Python for keyboard input, timing, and bitmap image processing. The fact that DOOM is not true 3D and was developed before graphics cards makes data transformations suitable for SQL possible. The code is on GitHub; versions made with regular expressions and in Microsoft Word are also available.
Why it matters
This work shows that viewing SQL as limited to data querying and management may not fully reflect the language’s expressive power. It offers a concrete example, particularly for database developers and those examining the limits of programming languages, of how an unusual workload such as game logic can be modeled using relational structures. DOOM’s structure, which does not use true 3D, and the fact that it was developed before graphics hardware were decisive in making this possible; therefore, the result does not mean that every graphics application would work similarly with SQL. The code on GitHub, along with the other versions created using regular expressions and Microsoft Word, shows how the same idea can be tested with different tools. The open question is which practical tasks this approach could meaningfully serve beyond being an entertaining demonstration.
Background
DOOM is not a new name in the FikirPilot archive: we published 3 news stories mentioning the name in the last 90 days; the most recent is dated September 15, 2026.