3 ms·

I think you mean it sounds as good as the article says it is. SpacetimeDB is single threaded by design, just like TigerBeetle by the way. The reason we changed

I think you mean it sounds as good as the article says it is. SpacetimeDB is single threaded by design, just like TigerBeetle by the way. The reason we changed from MVCC to single threaded design is that it's simply faster for almost all workloads. Measurably so! With MVCC we were doing more bookkeeping than actual work and perpetually causing cache coherency issues. "Technically sloppy" is an understatement. The article just gets several things plan incorrect about the durability guarantees, etc.

cloutiertyler 1mo ago
Since we're asking clankers: https://chatgpt.com/c/6a886e34-c784-83ea-8298-2d8215f5994a https://chatgpt.com/c/6a886e34-c784-83ea-8298-2d8215f5994a https://claude.ai/share/658d00e4-550a-470e-b4a3-7a71a06222cb 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.”
- cmrdporcupine 1mo ago
  hey tyler, ltns 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?
  - cloutiertyler 1mo ago
    Extraordinary claims perhaps, but correct ones nevertheless: https://spacetimedb.com/blog/benchmarking https://spacetimedb.com/blog/benchmarking. 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 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.

cloutiertyler 1mo ago

Since we're asking clankers: https://chatgpt.com/c/6a886e34-c784-83ea-8298-2d8215f5994a https://chatgpt.com/c/6a886e34-c784-83ea-8298-2d8215f5994a https://claude.ai/share/658d00e4-550a-470e-b4a3-7a71a06222cb 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.”

cmrdporcupine 1mo ago
hey tyler, ltns 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?
- cloutiertyler 1mo ago
  Extraordinary claims perhaps, but correct ones nevertheless: https://spacetimedb.com/blog/benchmarking https://spacetimedb.com/blog/benchmarking. 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 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.