Robot brain summarized:
"Your historical description may be completely accurate. Your request that the author substantiate the claim was warranted. But the source substantiates it extremely clearly. The blog’s concurrency conclusion is right. Its “hash table,” fairness, “cannot sync WAL,” and “questionable to call it a database” language is deliberately contemptuous and sometimes technically sloppy."
touche
"Technically sloppy" is an understatement. The article just gets several things plan incorrect about the durability guarantees, etc.
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.”
yeah my bot also flagged the parking_lot thing :-)
it was a hit piece with an unprofessional tone. but extraordinary claims get extraordinary responses
i do think dropping mvcc is an odd choice. do you at least let pure reads proceed while a single writer is active?
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.
This actually surprises me? I was a very early employee/contractor working on this product but left after 3 months. But this wasn't the shape it had when I was there. It would have been better described as a CoW tree of various sorts, which lets reads and writes advance on separate transactions and reconciles at commit with what I recall was fairly minimal lock-holding time.
When I was there there was no global lock being held while a WASM "reducers" was executing. They operated on their own separate transaction in their own thread.
I haven't looked at their source since -- and I really don't want to because I work on similar things I don't want IP contamination as last I looked they had some sort of weird license -- but there's been .. 3 years? of development on it since and I know Tyler well enough and he hired smart-ish people.
I had a lot of criticisms of what he was making and the way it was being made... but ehh....I would want to confirm in source that this claim is accurate, it makes me a bit suspicious of the accuracy and fairness of the rest of TFA.