SpacetimeDB 2.0's benchmarks are dishonest, reviewer says
SpacetimeDB: A Short Technical Review
A technical review of SpacetimeDB 2.0 finds its published benchmarks are not honest, comparing the database unfairly against competitors. The reviewer notes the product is an all-in-one database and application server with in-memory storage, a single global mutex, and an asynchronous write-ahead log. SpacetimeDB's own benchmarks show poor performance against competitors in an alternate test.
You don't need 'INSANE BENCHMARKS' to win at this.
- nemothekid
The SpacetimeDB launch video came up on my YouTube feed - and I was surprised the video didn't go at all into how it was implemented. I assumed it was proprietary magic, but then I was surprised to find it was opensource. That confused me more - to get the kind of semantics they were talking about I had assumed that it was pretty novel and if it was open source they should be leading with that.
Kind of bummed to see its essentially 2015-era React Flux in Rust around a mutex.
- JSR_FDED
I appreciate the very even-handed way this was written, not fanning flames but bringing it back to a choice between trade-offs that all DB developers can/should make.
- Groxx
Broadly enjoyed my read, though I do have a nitpick here:
>The absence of side effects or stalls cannot be enforced by the type system ...
Side effects is probably correct, but stalls would imply wasm code that calls out to a long-time blocking function - that's generally quite easy to type-system-ify, and wasm stuff often does so with promise-like constructs. So there would be a need for spacetimedb-side markers for "this func might do HTTP", but that kind of marker for WASM-contact-able code is very much a normal expectation.
If they don't have that kind of marker, and do allow blocking calls in their beta API, then yeah - huge problem with that kind of internal structure (shared global lock), completely agreed.