SQLDoom rendert Doom mit 1.300 Zeilen SQL — 89 CTEs als Spiel-Engine bei 35 fps

„Doom in einer Datenbank zu rendern, ist offensichtlich eine schlechte Idee“, schreibt Lukas Vogel in dem Blogbeitrag, der SQLDoom erklärt, sein Projekt, das Doom mithilfe einer SQL-Datenbank rendert. Die Architektur: Ein kleiner Python-Client übernimmt Eingabe, Ausgabe, Spiel-Timing und Frame-Anzeige, während dahinter eine Reihe von CedarDB-Tabellen die Spielgeometrie und den Spielzustand verfolgt. Das Spiel selbst besteht aus etwa 1.300 Zeilen SQL, verteilt auf 89 Common Table Expressions, die die Spiellogik implementieren und 35 Bitmap-Framebuffer pro Sekunde erzeugen.

SQLDoom ist ein großer Schritt gegenüber Vogels früherem Projekt DoomQL, das im vergangenen Jahr „einen Multiplayer-Shooter im Doom-Stil vollständig in SQL“ bauen wollte, aber am Ende bei einer raycasting-basierten, graustufigen ASCII-Annäherung landete. Die Version von 2026 rendert akkurate Bitmap-Ansichten der Hölle mit 35 fps, samt einer Debug-Ansicht, die Performance-Statistiken und Pipeline-Details zeigt.

Der Coup ist zugleich ein getarnter Datenbank-Benchmark: Einen Frame zu rendern bedeutet, Query-Pipelines auszuführen, die bei jedem Tick die Weltzustands-Tabellen verbrauchen, was Query-Planung, die Auswertung von Common Table Expressions und Materialisierung weit über typische OLTP-Workloads hinaus belastet — und genau darum geht es dem CedarDB-Team.

Eine Query-Engine ist eine Compute-Engine: Wenn Geometrie und Zustand in Tabellen leben, können Joins, CTEs und Aggregate die Mathematik pro Frame erledigen — der Framebuffer ist ein Query-Ergebnis.

Es beantwortet „Kann es Doom ausführen?“ auf der Abstraktionsebene, nicht auf der Geräteebene: keine Portierung auf neue Hardware, sondern neue Mathematik — relationale Queries als Rendering-Pipeline.

Die Zahlen machen es real statt konzeptionell: 1.300 Zeilen SQL, 89 CTEs, 35 Frames pro Sekunde akkurater Bitmap-Ausgabe.

Es baut auf dem eigenen früheren Scheitern des Autors auf — DoomQLs ASCII-Raycaster — und zeigt die Lücke zwischen „in SQL rechnerisch möglich“ und „in SQL engine-tauglich“.

Für ein Datenbank-Startup ist Doom ein Stresstest, den Marketingmaterialien nicht fälschen können: Query-Pipelines pro Frame legen Planungs- und Ausführungsperformance für jeden offen.

Engines sind nur Berechnungspipelines; wenn man ein System über seine vorgesehene Abstraktion hinaus treibt — SQL als Grafik-Pipeline —, lernt man genau, wo seine wirklichen Grenzen liegen.

SQLDoom wurde im Oktober 2026 mit einem langen technischen Blogbeitrag und dem Quellcode auf GitHub veröffentlicht; Ars Technica berichtete in derselben Woche darüber. Die Quelle nennt keine Folgepläne.