SQLDoom renderiza Doom com 1.300 linhas de SQL — 89 CTEs como motor de jogo a 35fps

"Renderizar Doom em um banco de dados é obviamente uma má ideia", escreve Lukas Vogel no post de blog que explica o SQLDoom, seu projeto que renderiza Doom usando um banco de dados SQL. A arquitetura: um pequeno cliente em Python cuida da entrada, da saída, da temporização do jogo e da exibição dos quadros, enquanto, por trás dele, uma série de tabelas do CedarDB acompanha a geometria e o estado do jogo. O jogo em si tem cerca de 1.300 linhas de SQL distribuídas em 89 expressões de tabela comuns (CTEs), que implementam a lógica do jogo e geram 35 framebuffers de bitmap por segundo.

O SQLDoom é um grande avanço em relação ao projeto anterior de Vogel, o DoomQL, que no ano passado se propôs a construir "um shooter multijogador no estilo Doom inteiramente em SQL", mas acabou resultando em uma aproximação em ASCII em escala de cinza baseada em raycasting. A versão de 2026 renderiza visões bitmapped precisas do Inferno a 35 fps, completas com uma visão de depuração que mostra estatísticas de desempenho e detalhes do pipeline.

O feito também funciona como um benchmark de banco de dados disfarçado: renderizar um quadro significa executar pipelines de consulta que consomem as tabelas de estado do mundo a cada tick, o que exige do planejamento de consultas, da avaliação de expressões de tabela comuns e da materialização muito além do que cargas de trabalho OLTP típicas exigem — o que é precisamente o objetivo para a equipe do CedarDB.

Um motor de consultas é um motor de computação: se a geometria e o estado vivem em tabelas, junções, CTEs e agregações podem fazer a matemática por quadro — o framebuffer é um resultado de consulta.

Responde a "será que roda Doom" no nível da abstração, não no nível do dispositivo: não é uma portabilidade para novo hardware, mas nova matemática — consultas relacionais como pipeline de renderização.

Os números tornam isso real em vez de conceitual: 1.300 linhas de SQL, 89 CTEs, 35 quadros por segundo de saída bitmapped precisa.

Baseia-se no próprio fracasso anterior do autor — o raycaster ASCII do DoomQL — mostrando a diferença entre "computacionalmente possível em SQL" e "de nível de motor em SQL".

Para uma startup de banco de dados, Doom é um teste de estresse que materiais de marketing não conseguem falsificar: pipelines de consulta por quadro expõem o desempenho de planejamento e execução a qualquer pessoa.

Motores são apenas pipelines de computação; quando você leva um sistema além de sua abstração pretendida — SQL como pipeline gráfico — você descobre exatamente onde estão seus limites reais.

O SQLDoom foi publicado com um longo post técnico de blog e o código-fonte no GitHub em outubro de 2026; a Ars Technica o cobriu na mesma semana. A fonte não relata planos de continuidade.