News for hackers. Stuff that matters.

lvogel

Re:Building a DOOM-like multiplayer shooter in pure SQL on Tuesday September 09, 2025 @04:44PM (#45188738)
That's just my age showing, I guess. For me, all 2.5D shooters are DOOMlikes. I was actually first thinking about calling it a Quake-like since IMHO that is much more well known for its multiplayer, but then I never got around to implement powerups and all the other stuff people might have expected.
Re:Building a DOOM-like multiplayer shooter in pure SQL on Tuesday September 09, 2025 @04:42PM (#45188687)
Love that you liked it! Your project was the inspiration and showed me the insanity was actually feasible :D
Re:Building a DOOM-like multiplayer shooter in pure SQL on Tuesday September 09, 2025 @04:41PM (#45188661)
Yea, I actually thought of the viability of SQL for games while working on DOOMQL. It's just so easy to express a lot of game logic in SQL queries. As an avid OSRS player I was thinking about doing a simple MUD/MMO next.

Thanks for the pointer to SpacetimeDB - haven't heard of it before!

Re:Building a DOOM-like multiplayer shooter in pure SQL on Tuesday September 09, 2025 @01:50PM (#45185628)
If you want to take a look at the source code, here's the repo! https://github.com/cedardb/DOOMQL
Re:Optimistic Locking in B-Trees on Friday March 07, 2025 @01:04PM (#43292453)
The version is just an atomic integer assigned to that btree node which is monotonically increasing. Each writer increases the version when it releases the lock IF it has modified the node.

Wraparounds are only a theoretical issue. There would have to be exactly UINT64_MAX writers between a reader first checking the version and verifying the version.

Tell me about it... Was just too expensive compared to flash. But the tech was definitely awesome and I hope it'll come back in one way or another.

When designing CedarDB, we recently had multiple instances where we thought: "If we had just a few KiB of Optane here ... "

> Ultimately, a reliable non-volatile write cache, sized for your workload is the answer.

Author here, I agree! It's quite sad that we need such an involved solution to offset the inherent complexity of the flash medium (latency spikes, erase blocks, ...). We nearly had the perfect solution with Optane[1]: 100ns latency, instantly persisted writes and all that good stuff.

I'm still not over Intel killing it while I did my PhD on it.

[1] https://en.m.wikipedia.org/wiki/3D_XPoint

Yes, the way it is currently implemented, the build side has to fit into RAM. There is no inherent reason we couldn't also spool to disk, but we haven't implemented that yet.
Depends on your use case. Redis is a key-value store that is optimized for simpler workloads and is designed as a caching layer.

Umbra, on the other hand, is a full fledged, ACID compliant relational database systems with all bells and whistles.

However, Umbra can process multiple 100ks of transactions per second. If you're interested in more details, take a look at Figure 6 in this research paper: https://db.in.tum.de/~freitag/papers/p2797-freitag.pdf

Disclosure: I work for CedarDB (https://cedardb.com), the commercial spinoff of Umbra.

Yes, we do use io_uring
Re:Speedy Transactions in Multicore In-Memory Databases on Monday February 27, 2023 @08:05AM (#34955927)
all VLDB papers are also completely open access. You can find e.g. last year's papers here: http://vldb.org/pvldb/volumes/15.