SQLDoom renderiza Doom con 1300 líneas de SQL: 89 CTE como motor de juego a 35 fps

«Renderizar Doom en una base de datos es obviamente una mala idea», escribe Lukas Vogel en la entrada de blog que explica SQLDoom, su proyecto que renderiza Doom usando una base de datos SQL. La arquitectura: un pequeño cliente en Python gestiona la entrada, la salida, la temporización del juego y la visualización de fotogramas, mientras que detrás una serie de tablas de CedarDB rastrea la geometría y el estado del juego. El juego en sí son unas 1300 líneas de SQL repartidas en 89 expresiones de tabla comunes, que implementan la lógica del juego y generan 35 búferes de fotogramas de mapa de bits por segundo.

SQLDoom supone un gran salto respecto al proyecto anterior de Vogel, DoomQL, que el año pasado se propuso construir «un shooter multijugador tipo Doom enteramente en SQL» pero acabó en una aproximación en ASCII en escala de grises basada en raycasting. La versión de 2026 renderiza vistas de mapa de bits precisas del Infierno a 35 fps, con una vista de depuración que muestra estadísticas de rendimiento y detalles del pipeline.

La hazaña funciona además como un benchmark de base de datos disfrazado: renderizar un fotograma implica ejecutar pipelines de consultas que consumen las tablas de estado del mundo en cada tick, lo que somete a la planificación de consultas, la evaluación de expresiones de tabla comunes y la materialización a una carga muy superior a las típicas cargas de trabajo OLTP; que es precisamente el objetivo para el equipo de CedarDB.

Un motor de consultas es un motor de cómputo: si la geometría y el estado viven en tablas, las uniones, las CTE y las agregaciones pueden hacer los cálculos de cada fotograma; el búfer de fotogramas es un resultado de consulta.

Responde a «¿puede ejecutar Doom?» en el nivel de abstracción, no en el nivel del dispositivo: no es un port a nuevo hardware, sino matemáticas nuevas: consultas relacionales como pipeline de renderizado.

Las cifras lo hacen real en lugar de conceptual: 1300 líneas de SQL, 89 CTE, 35 fotogramas por segundo de salida de mapa de bits precisa.

Se basa en el fracaso previo del propio autor —el raycaster ASCII de DoomQL— y muestra la brecha entre «computacionalmente posible en SQL» y «de nivel de motor en SQL».

Para una startup de bases de datos, Doom es una prueba de estrés que los materiales de marketing no pueden falsear: los pipelines de consultas por fotograma exponen el rendimiento de planificación y ejecución a cualquiera.

Los motores no son más que pipelines de cómputo; cuando llevas un sistema más allá de su abstracción prevista —SQL como pipeline de gráficos— aprendes exactamente dónde están sus límites reales.

SQLDoom se publicó con una extensa entrada de blog técnica y el código fuente en GitHub en octubre de 2026; Ars Technica lo cubrió esa misma semana. La fuente no informa de planes de seguimiento.