We ported the original Doom to SQL
- ID
- 31877
- Status
- summarized
- Published
- 04 Oct 2026, 6:14 AM
- Fetched
- 05 Oct 2026, 9:21 PM
- Provider
- Hacker News
- Category
- dev-community
- Original URL
- https://cedardb.com/blog/sqldoom/
- Source URL
- https://hnrss.org/best
Summary
- Score
- 6.5
- Created
- 05 Oct 2026, 9:34 PM
- Tags
- Audience
- developersvibe_codersdatabase_learners
What happened
Lukas Vogel ported the original 1993 Doom's game logic and renderer to pure SQL, running the whole game loop inside a database at the original 35 FPS with the renderer producing a full 320x200 RGB frame buffer at up to 60 Hz on an AMD Ryzen 7 7840U laptop. Python only handles keyboard input, tic timing, and bitmap display; deathmatch works with four first-come-first-served slots on EU and US servers running the shareware episode. It follows the author's earlier DOOMQL project, which used raycasting and was closer to Wolfenstein 3D; this version handles Doom's BSP trees for correct depth ordering, arbitrary wall angles, and varying floor heights.
Why it matters
This is a concrete demonstration of how far a SQL engine's query planner and execution can be pushed — game state, BSP traversal, and per-pixel rendering all as queries — so database learners get a tangible benchmark for what set-based computation can express beyond CRUD. It is not a signal to change your stack; treat it as a stress test you can read, and a fun source of ideas for using UDFs and query composition. The playable servers mean you can inspect live game state via SQL while queued, which is a rare hands-on way to see a database as an application runtime.
Discussion angle
What does the BSP-vs-raycasting distinction teach about choosing algorithms when your execution engine is a query planner — and where does SQL stop being a reasonable runtime?