DOOMbench: When Database Performance Meets First-Person Shooters

In the evolving landscape of database technologies, performance benchmarking often relies on abstract metrics like queries per second or response times that fail to capture the real-world experience of using a database system. CedarDB's DOOMbench presents a refreshingly different approach: running a multiplayer DOOM-like game entirely in SQL to visually demonstrate how different database architectures handle mixed workloads.

The Genesis of DOOMQL

Last year, CedarDB introduced DOOMQL, a multiplayer DOOM-like game that runs entirely within SQL using recursive CTEs for raycasting and a true client-server architecture where players connect directly to the database. The project gained significant attention when it reached the front page of Hacker News, demonstrating the technical feasibility of complex computational tasks expressed purely in SQL.

DOOMbench builds upon this foundation, transforming DOOMQL into a comprehensive stress test for various data stack architectures. Rather than presenting dry latency numbers and throughput charts, DOOMbench generates videos that immediately convey performance differences in an intuitive way.

Three Dimensions of Database Performance

The benchmark effectively tests three critical dimensions of database performance:

1. Raw Analytical Performance: DOOMQL uses recursive CTEs to render a game world in ASCII art through raycasting—a computationally intensive task that pushes analytical capabilities to their limits.

2. Transaction Processing: The game implements a client-server architecture where players connect directly to the database, inserting inputs into an inputs table. While this doesn't generate massive transaction volumes (approximately 50 transactions per second for 10 players), latency is crucial. High ping in multiplayer gaming demonstrates why transactional responsiveness matters.

3. Atomicity: The game requires strict ACID guarantees to prevent inconsistencies like players being shot by opponents who are already dead on their screen. While most modern databases implement these guarantees, DOOMbench reveals how different architectures handle these requirements under load.

Database Architectures in Action

The benchmark tests several architectural approaches to handling these mixed workloads:

Pure OLTP (Postgres)

Postgres, a battle-tested transactional database, struggles with the analytical demands of DOOMQL. While it can process approximately 10 ticks per second, rendering a single view takes multiple seconds. The player's view becomes severely out of sync with the actual game state, creating an unplayable experience where actions aren't reflected in the visual output.

OLAP with ETL Pipeline (Postgres + DuckDB)

This approach separates transactional and analytical processing, using Postgres for handling player inputs and DuckDB for rendering, connected by a Change Data Capture (CDC) pipeline that copies data once per second. While DuckDB achieves respectable frame rates (10 FPS compared to Postgres' 0.3), 9 out of 10 frames render stale data due to the replication lag. This demonstrates how ETL pipelines, while improving analytical performance, introduce unacceptable delays for interactive applications.

Nesting Doll Approach (pg_clickhouse)

This approach attempts to improve analytical performance by bolting a specialized engine (ClickHouse) onto Postgres through pg_clickhouse. While this can accelerate table scans, the fundamental bottleneck remains Postgres' query optimizer and execution engine. For DOOMQL's complex queries on small tables, this approach provides minimal improvement over pure Postgres.

HTAP (CedarDB)

CedarDB represents a new generation of Hybrid Transactional/Analytical Processing databases designed from the ground up to handle both workloads natively. Rather than forcing a choice between specialized OLTP or OLAP architectures, CedarDB assumes modern hardware realities—fast storage, abundant RAM, and multiple cores—and builds a coherent architecture that excels at both transactional and analytical processing.

The results are immediately apparent: CedarDB achieves approximately 30 FPS at 30 ticks per second with minimal lag (44 milliseconds from keypress to visible result). While not competitive with professional gaming standards, this performance makes the game actually playable and demonstrates the potential of HTAP architectures.

The DOOM Benchmark Methodology

DOOMbench measures four key metrics:

1. Tickrate: Pure OLTP measurement without rendering, testing how quickly the database can process game ticks.
2. Static FPS: Pure OLAP measurement without movement, testing raw analytical query throughput.
3. Median Lag: The time from button press to visible result, capturing end-to-end performance.
4. DOOMscore: HTAP benchmark testing combined performance while maintaining the original DOOM tick rate of 35 Hz.

Each system runs the same DOOMQL codebase on identical hardware, with database-specific SQL overrides where needed for compatibility. The benchmark includes video replays of each system's performance, providing visual context for the numerical results.

The Significance of HTAP

The traditional separation between OLTP and OLAP systems emerged from hardware limitations—particularly the catastrophically slow random I/O of spinning disks. OLTP systems optimized for row-oriented writes, while OLAP systems optimized for column-oriented scans. This specialization required complex ETL pipelines to move data between systems.

Modern hardware has largely eliminated these constraints. NVMe SSDs can handle hundreds of thousands of random IOPS, and servers often have enough RAM to keep entire hot datasets in memory. HTAP databases like CedarDB reflect this new reality by designing architectures that don't force artificial trade-offs between transactional and analytical processing.

This shift matters significantly for modern applications:

• Interactive dashboards that require fresh data
• Real-time analytics where decisions depend on current information
• AI agents acting on their own decisions based on recent data
• Any system requiring immediate feedback on recent data

Beyond the Contrived Workload

The article acknowledges that DOOMQL represents a contrived workload, using obscure SQL features like recursion and complex string manipulation. However, it argues that the underlying patterns—making observations on fresh data—appear throughout modern applications.

The visual nature of the benchmark provides an advantage over traditional metrics. While latency numbers can be difficult to contextualize, a video of a database struggling to render a game frame makes performance issues immediately apparent.

Open Source and Community Engagement

CedarDB has open-sourced DOOMbench, inviting contributions from the database community. The benchmark currently supports Postgres-compatible systems, with plans to expand to other database types. This approach helps address the common criticism that vendor benchmarks are self-serving by allowing independent verification and extension.

Conclusion: Is HTAP Worth It?

Whether HTAP architectures like CedarDB are worth adopting depends on your specific workload. For applications where stale data is acceptable—such as reports read after a coffee break—traditional architectures may remain sufficient. However, for systems requiring immediate feedback on recent data, whether for human users or automated agents, HTAP can be transformative.

DOOMbench represents more than just a clever benchmark; it's a demonstration of how database architecture is evolving to meet modern application demands. As the line between transactional and analytical processing continues to blur, HTAP databases may become increasingly essential for the real-time, data-intensive applications of the future.

For those interested in running DOOMbench themselves, the code is available with all database systems dockerized for easy setup. Those wanting to explore CedarDB further can get started through their documentation or contact the team directly.

The benchmark page at cedardb.com/doombench provides complete results and video demonstrations of each system's performance.