"Can it run Doom?" now applies to databases, as the author of DOOMQL has released a far more visually accurate port. There's a saying: "Be careful what you wish for." In 2025, we wrote a piece about a database boffin coming up with a version of Doom that was written in SQL. It was neat, but the visuals were nearer to 3D Monster Maze than to the 90s pixel blaster. We commented, "If persuading SQL to do the entire rendering pipeline is a 'bad idea,' we cannot wait for a terrible one." And so here we are. The author, Lukas Vogel, has been at it again and ported both Doom's game logic and renderer to SQL, running it in a database. Python handles timing, keyboard input, and bitmap display, but the rest comes from SQL queries and the CedarDB database. DOOMQL was an undeniably impressive thing. However, Vogel told The Register, "Someone on Hacker News complained last year when I did the first iteration that that one was more Wolfenstein-like because I used raycasting instead of BSP-tree traversal which was *the thing* that made Doom revolutionary. "So I obviously couldn't let that stand." Which brings us to SQLDoom. Doom, ported to SQL. In his blog, Vogel noted the ground rules for the port. Unlike DOOMQL, this had to look like real Doom. The rendering had to be purely SQL-based: "the only acceptable SQL output is a table or a bitmap encoding exact RGB values for every pixel," and the game loop also had to be purely SQL-based. Vogel told us, "I was very thrilled to find out that porting the real Doom was a) feasible and b) the performance was actually *better* than the much more barebones approach from last year! "Also, at some point I started actually playing it for fun in my free time, which is still a very strange feeling. I intended it as a tech demo, but it just feels like the real Doom, even though it doesn't share a single line of code with any existing Doom port. So I wanted to see how far I could take it. "In the end, I even got deathmatch to work." According to Vogel, the game is perfectly playable on his laptop (using a Ryzen 7 7840U), and multiplayer games can be played online using EU and US servers. We found the server performance a little sluggish – likely more due to the servers than the port – although getting SQL to jump through these hoops is something that, only a few short years ago, would be unimaginable. It's worth keeping in mind that this is a thinly veiled demonstration of the capabilities of CedarDB. It's a compiling database system where complex queries are eventually compiled to machine code. Still, it's hard not to get swept up in Vogel's enthusiasm and the fact that this is Doom… running in a database. Certainly this is a lot more fun than recreating yet another online store for yet another interminable keynote. ®

Cloudflare Data Platform on Thursday received a bland new brand name, Basin, and promotion from beta status to general availability. Under the tub-themed moniker, Cloudflare Pipelines, R2 Data Catalog, and R2 SQL become Basin Pipelines, Basin Catalog, and Basin SQL respectively. The company's evocation of washroom fixtures doesn't quite align with its stable of more literal product names – Sandboxes, Workers, Email Services, and so on. But given that the occasion is Cloudflare Birthday Week, which itself fails to respect the concept of "day," straightforward naming may be expecting too much. At least Cloudflare didn't latch onto any of the worse water storage metaphors for collections of information, like data lake, lagoon, puddle, bowl, or cesspool. "Sink" was also on this list, but it turns out Cloudflare has already deployed the term, as we'll see below. Cloudflare CTO Dane Knecht pitched the renamed platform as an easier alternative to standing up a bunch of hardware for observing data. "With Cloudflare Basin, we are bringing the same serverless model that developers expect from Cloudflare to analytics: no clusters to manage, no unnecessary data movement, and open standards that keep customers in control of their data," he said. Basin's appeal is based on lack of lock-in – because it relies on Apache Iceberg – and lack of egress fees, so data can move freely across cloud regions. Rival services from hyperscalers (Amazon S3, Google Cloud Storage, and Azure Blob Storage) impose egress fees. Cloudflare Basin represents an invitation for companies to store data in R2 Data Catalog and then process it with Basin SQL or any of various external query engines like DuckDB, PyIceberg, Snowflake, Spark, StarRocks, or Trino. And that's what Cloudflare is highlighting in its menu of canned customer quotes. Here's Julien Grobbelaar, head of platform at Bobsled: "Basin allows us to build data products that can be made accessible in any region of every major data and AI platform, all at production-grade reliability and a fraction of the cost thanks to zero egress fees." Cloudflare claims as much: "Querying data using tools from different clouds, platforms, or regions carries no transfer fees." And yet there are fees. As Cloudflare explains, "Egressing directly from R2, including via the Workers API, S3 API, and r2.dev domains does not incur data transfer (egress) charges and is free. If you connect other metered services to an R2 bucket, you may be charged by those services." If Basin Pipelines is used to load streaming data into Apache Iceberg or Parquet in R2, Cloudflare charges for delivering data to those sinks after the included allowance. Cloudflare labels this pricing dimension "Sinks (egress)." At the bottom of every data lake, sink, pool, or basin, there's a drain for cash. ®