cloutiertyler

Yep, that’s exactly what it is.

Hardly your fault! It’s the responsibility of the person writing the article to do the technical diligence. Nevertheless did want to address it.

You don’t need CockroachDB for high availability though.

It wouldn’t. SpacetimeDB Cloud is not single node. And before you say it’s not open source, neither is CRDB.

I'm not sure I follow. SpacetimeDB Cloud has the same exact behavior as CRDB in terms of tolerating single node failure and loss of availability.

The SpacetimeDB Cloud version runs with distributed replication, so it continues to be available on the other nodes.

On the SpacetimeDB Standalone (single node) version, you lose your data, same as you would with Postgres or Sqlite.

Is it really not more expensive? I haven't operated a large scale Spanner cluster, but the numbers would suggest it's quite a bit more expensive. I suppose it's workload dependent is what you're saying?

> which is guaranteeing that single node failures can be tolerated with zero data loss or loss of availability

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.

Hear hear

I don't have the whole story for you, but the key is that SpacetimeDB transactions are not interactive. The TigerBeetle team talks about this a lot as well.

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.

I am the author of OPs article (SpacetimeDB cofounder). These are all fair caveats/criticisms.

> 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.

We originally did MVCC and it was actually worse performance (in our implementation, I grant), but that's what OPs article is about. We spent a lot of money finding out that a lock is more performant.

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 (heh).

I know people aren't going to put more than a few minutes into verification, so that's why I suggested it. I'm not really sure what else to do. It really is all there in the code.

Yes, I mean we do not expose any data external to the database that is not written persistently to disk (by default). In our case that means:

- 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