CedarDB runs Doom’s game logic and rendering in SQL
SQLDoom puts Doom’s core logic, state and renderer inside CedarDB, while a thin Python client handles input, timing and display.
By Renata Fuchs · Policy Reporter
· 3 min read
CedarDB Doom SQL project SQLDoom runs the 1993 game’s logic, game state and full-frame renderer inside the database, according to CedarDB and independent reporting by The Register. Python remains outside the database for timing, keyboard input and bitmap display, a boundary that makes this a systems demonstration rather than a conventional game-engine architecture.
CedarDB says SQLDoom runs its game loop at 35 Hz, the rate used by the original game, and can render a 320-by-200 RGB frame buffer at up to 60 Hz on the author’s Ryzen 7 7840U laptop. Those performance figures are developer-reported, not independently reproduced measurements.
Can CedarDB run Doom in SQL?
Yes, within the project’s stated constraints. CedarDB says the SQL code handles game logic, state and rendering, with state stored in database tables. The client triggers game ticks, collects keyboard input and displays the returned image. The game loop runs on a fixed schedule, while the renderer can be requested separately as a function of the current state tables.
The distinction matters because “running Doom in a database” can describe anything from using a database for storage to putting core engine work in queries. SQLDoom’s claim is narrower and more substantive: the simulation and renderer reside in CedarDB, while device-facing work stays in Python.
The project is a follow-up to CedarDB’s 2025 DOOMQL experiment. That earlier version used raycasting and ASCII-style graphics, which made it closer to Wolfenstein 3D in its rendering approach than to Doom. SQLDoom instead uses Doom-style binary space partitioning, or BSP-tree traversal, which CedarDB says supports depth ordering, textures, angled walls and varying floor heights.
What has been demonstrated, and what has not?
CedarDB says SQLDoom includes multiplayer and offers access to servers in Europe and the US. It also says deathmatch works, with four slots on its hosted demonstration. The Register reported that it found hosted server performance somewhat sluggish, while suggesting that might reflect the servers rather than the port itself. That observation is separate from CedarDB’s laptop performance claims.
The company’s wider DoomBench project explains why it chose this kind of workload. It uses a Doom-like SQL server to put rendering-heavy query work alongside latency-sensitive input and state updates, illustrating the tension between analytical processing and transaction processing. CedarDB’s comparisons in that project are vendor-authored demonstrations, not an independent ranking of database systems.
The practical result is not an argument for building games on relational databases. It is evidence that CedarDB can execute a deliberately unusual SQL workload: a game simulation plus pixel-level rendering. The Register described the port as a demonstration of CedarDB’s capabilities, including its ability to compile complex queries to machine code.
This story draws on original reporting from The Register.
