If you don't believe me, perhaps you'd believe the TigerBeetle team who also made their database single threaded by design.

Perhaps you'd be interested in reading our technical response: https://spacetimedb.com/blog/benchmarking

My comment was unrelated to benchmarking and I don’t see anything in that blogpost addressing my comment.

Also you’re spamming the same comment up and down this thread. Did this post upset you?

Yes, of course it did. This article makes factually wrong claims about the database I've spent 6+ years building.

Your comment was about whether SpacetimeDB was "just a hashmap behind a RwLock" and the blog post I linked addresses that question. Namely, it does have a RwLock, but that is by design and produces better results than the alternative.

Better results than the alternative, assuming your use case is to find two accounts by indexed ID, check a balance, and update two rows. And you have a small in-memory dataset, tiny rows, indexed point lookups, very little application computation, no external I/O, no joins, no analytical queries, no large scans, no disk-capacity pressure, thousands of independent requests available for pipelining, and deliberate hot-row contention. Or in other words, you have the perfect conditions for a...hashmap behind an RwLock!

Hm I wonder why people find this benchmark unfair...

You're just describing OLTP transactions, which is exactly what OLTP benchmarks are designed to test.