alt Hacker News> It sounds like transactions by default are required to be written to disk before completion
They are yolo mode by default with periodic fsync and a big mutex around every reducer: https://strn.cat/posts/spacetime/ (granted things may have changed since that blog post)
> I can't recall seeing a network-bound cluster
I saw some of these (most packets per second not bandwidth) in the Firebase Realtime Database because changes get broadcast to many users. Since SpacetimeDB is made for games this is the same synchronization effect. Traditional databases don’t do this which is why Cockroach wouldn’t have seen it.
I concede that we do have a big lock. But that is only because we did the alternative first and it performed worse, which is what OPs article is about.
Reposting what I posted below regarding the strn.cat article:
I'm a cofounder of SpacetimeDB (and the author of OPs article). The https://strn.cat/posts/spacetime/ article has several substantial errors. I've spoken with Vicent directly about them.
Most notably, almost the entire commentary about durability is incorrect. SpacetimeDB does not acknowledge anything before data is fully persisted to disk, even though he claims it does. Clients CAN chose to listen before that, but you can do the same thing in Postgres if you want.
There is no 50 ms delay to writing to disk. The article is mostly nonsense.
Ask Claude yourself: https://github.com/clockworklabs/SpacetimeDB
He spent 15 minutes looking at our code (by his own admission), having never written a database storage engine before AFAIK, and made a pronouncement that SpacetimeDB wasn't a good database. Crazy stuff.