Database expert runs Doom in SQL with just 5,900 lines of code
- ID
- 31639
- Status
- summarized
- Published
- 04 Oct 2026, 10:00 PM
- Fetched
- 04 Oct 2026, 11:21 PM
- Provider
- Tom's Hardware
- Category
- technology
- Original URL
- https://www.tomshardware.com/video-games/pc-gaming/database-expert-runs-doom-in-sql-with-just-5-900-lines-of-code-1-300-line-graphical-renderer-spans-89-different-tables-full-featured-sqldoom-is-the-sequel-to-embryonic-doomql
- Source URL
- https://www.tomshardware.com/feeds/all
Summary
- Score
- 5.5
- Created
- 04 Oct 2026, 11:22 PM
- Tags
- Audience
- developersdatabase_learnersvibe_coders
What happened
A Tom's Hardware write-up reports a project called SQLDoom that implements Doom inside SQL, at roughly 5,900 lines of code, including a 1,300-line graphical renderer spread across 89 tables. It is described as the sequel to an earlier, less complete effort called DoomQL. The article body available here is almost entirely subscription and newsletter boilerplate, so the only concrete figures are those in the headline: 5,900 lines, 1,300 lines of renderer, and 89 tables.
Why it matters
If you are learning SQL beyond SELECT and JOIN, this is a concrete reference point for what recursive CTEs, stored procedures and set-based logic can be pushed into — 89 tables and a renderer implemented in the database rather than in application code. It is not something to ship: treat it as a stress test of how far you can stretch a relational engine, and as a reminder that the database is a compute environment you can practice advanced query patterns in, not just a place to store rows.
Discussion angle
Where is the line between 'clever demo' and 'bad architecture'? Walk through what 89 tables for a renderer implies about query complexity and performance, and ask whether recursive CTEs are worth learning for real work or only for stunts like this.