If you mostly use chat-style AI and you're trying not to fall behind on new tools, DOOMQL is easy to misread. You see a game running through SQL and the obvious takeaway is: "wow, SQL can do 3D now." That is exactly how people burn time, budget, and attention on the wrong part.
The more valuable takeaway is simpler: Pure SQL is most useful here not for the picture, but for the atomic state machine. In plain English, that means the whole game state moves forward in one all-at-once update. In CedarDB's demo, bullets, hits, kills, and respawns happen in one transaction to keep each tick consistent [S001]. That is the part that can change your next decision.
The flashy screen is real, but it is also the weaker lesson. The sample shown is only 128x64, running at about 33 ms per frame, or roughly 30 frames per second. The author also says the pure-SQL graphics side works but is hard to keep working [S001]. So the wrong conclusion is "SQL can replace a game engine." The stronger conclusion is that transaction logic can handle more state-update work than many people assume.
A new demo is worth your attention not because it lists more features, but because it changes your next decision. My read on DOOMQL is: do not chase it as proof that SQL should become your game engine. Notice it as proof that the most useful part of pure SQL here is the atomic state machine. Boundary: this is CedarDB's own DOOMQL demo, not a claim about every SQL database, and the evidence pack does not include hardware or OS details. Share this with the person who is about to learn the wrong lesson from the 3D angle.