SQLDoom rend Doom avec 1 300 lignes de SQL — 89 CTE comme moteur de jeu à 35 fps

« Rendre Doom dans une base de données est manifestement une mauvaise idée », écrit Lukas Vogel dans l'article de blog expliquant SQLDoom, son projet qui rend Doom à l'aide d'une base de données SQL. L'architecture : un petit client Python gère l'entrée, la sortie, la synchronisation du jeu et l'affichage des images, tandis qu'en arrière-plan une série de tables CedarDB suit la géométrie et l'état du jeu. Le jeu lui-même représente environ 1 300 lignes de SQL réparties sur 89 expressions de table communes, qui implémentent la logique du jeu et génèrent 35 tampons de trame bitmap par seconde.

SQLDoom constitue une avancée majeure par rapport au précédent projet DoomQL de Vogel, qui visait l'an dernier à construire « un jeu de tir multijoueur de type Doom entièrement en SQL » mais avait abouti à une approximation ASCII en niveaux de gris fondée sur le raycasting. La version 2026 rend des vues bitmap fidèles de l'Enfer à 35 fps, avec en plus une vue de débogage montrant les statistiques de performance et les détails du pipeline.

Le coup d'éclat fait aussi office de benchmark de base de données déguisé : rendre une image signifie exécuter des pipelines de requêtes qui consomment les tables d'état du monde à chaque tick, ce qui sollicite la planification de requêtes, l'évaluation des expressions de table communes et la matérialisation bien au-delà des charges OLTP typiques — ce qui est précisément l'objectif pour l'équipe de CedarDB.

Un moteur de requêtes est un moteur de calcul : si la géométrie et l'état vivent dans des tables, les jointures, les CTE et les agrégats peuvent effectuer les calculs image par image — le tampon de trame est un résultat de requête.

Cela répond à « peut-il faire tourner Doom » au niveau de l'abstraction, pas au niveau de l'appareil : non pas un portage vers un nouveau matériel, mais de nouvelles mathématiques — des requêtes relationnelles comme pipeline de rendu.

Les chiffres rendent cela réel plutôt que conceptuel : 1 300 lignes de SQL, 89 CTE, 35 images par seconde de sortie bitmap fidèle.

Cela s'appuie sur l'échec antérieur de l'auteur lui-même — le raycaster ASCII de DoomQL — montrant l'écart entre « computationnellement possible en SQL » et « de qualité moteur en SQL ».

Pour une startup de bases de données, Doom est un test de charge que les supports marketing ne peuvent pas falsifier : les pipelines de requêtes image par image exposent la performance de planification et d'exécution à tous.

Les moteurs ne sont que des pipelines de calcul ; lorsqu'on pousse un système au-delà de son abstraction prévue — le SQL comme pipeline graphique — on apprend exactement où se situent ses limites réelles.

SQLDoom a été publié avec un long article de blog technique et le code source sur GitHub en octobre 2026 ; Ars Technica en a parlé la même semaine. La source ne rapporte aucun projet de suite.