cloutiertyler
On the SpacetimeDB Standalone (single node) version, you lose your data, same as you would with Postgres or Sqlite.
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.
We solve this with distributed state machine replication. You don't need multiple writers to solve the single node failure problem. You only need multiple writers for a write throughput scaling problem.
They're separate problems.
The TL;DR is that because you're not holding locks across the network (as is the case in Postgres), your server code can complete transactions in single digit microseconds, rather than milliseconds. And the practical effect is you can do many more transactions per second as a result.
> The benchmarks are completely meaningless for that use case.
I wouldn't say completely meaningless, but it isn't a game benchmark that's true. We feel very comfortable that it's the most performant backend for persistent games though. We were trying to show it's also more performant for web use cases.
> 90% (or more) just waiting on timers to finish
This is not correct. It's mostly processing player movement transactions. We do about 50 million an hour.
Calling it a "hashtable" is something that only someone who hasn't built a DB engine would do. It's incredibly naive. It discounts the complexity of execution, atomicity, durability, constraint validation, migrations, query planning, incremental query evaluation, down to zero. It really makes it sound like he has absolutely no idea what he's talking about.
Besides, it's a btree.
- Returning it as a result to a SQL query - Sending it to clients as part of a subscription - Or a return value to the caller
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.
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.
I can say that your last paragraph is essentially correct though. It works exactly that way.
The article says that we don't provide strong durability guarantees. Pure ipse dixit. And IIRC he's already cleaned it up a little.
The shamelessness with which people published bogus claims about SpacetimeDB after this was really really astonishing. And so many were quick to dismiss the overall results based on some handwaving arguments. I wasn't prepared for it.
We should have held off on publishing until we had a deep technical blog on the subject.
If you haven't read https://spacetimedb.com/blog/benchmarking you should give it a read.
It seems like an odd choice perhaps, but I had the numbers to prove that it was simply measurably worse overall performance for most OLTP workloads.
IIRC, we don't let pure reads read the committed state while a transaction is underway. We can certainly do that in the future, but we're so far out ahead of typical database performance for most OLTP workloads we haven't even bothered.
https://chatgpt.com/c/6a886e34-c784-83ea-8298-2d8215f5994a
https://claude.ai/share/658d00e4-550a-470e-b4a3-7a71a06222cb
> In particular, these statements should not be relied on:
> readers wait “up to 0.5 ms” because of parking_lot;
> all reducers/views are Wasmtime/WASM;
> reads normally happen through Views;
> external side effects are merely something reducer authors must avoid;
> durable/confirmed reads are an unusual opt-in intended only > for non-ephemeral data;
> 50 ms is the normal/current durability delay;
> SpacetimeDB has no meaningful replication;
> the benchmark numbers themselves are simply “not true.”
"Technically sloppy" is an understatement. The article just gets several things plan incorrect about the durability guarantees, etc.