Hacker News Reader

Comment by rockwotj | Hacker News Reader

> It sounds like transactions by default are required to be written to disk before completion

They are yolo mode by default with periodic fsync and a big mutex around every reducer: https://strn.cat/posts/spacetime/ (granted things may have changed since that blog post)

> I can't recall seeing a network-bound cluster

I saw some of these (most packets per second not bandwidth) in the Firebase Realtime Database because changes get broadcast to many users. Since SpacetimeDB is made for games this is the same synchronization effect. Traditional databases don’t do this which is why Cockroach wouldn’t have seen it.

View on HN

I concede that we do have a big lock. But that is only because we did the alternative first and it performed worse, which is what OPs article is about.

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.

What happens if the disk dies?

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.

So, in short, I think I agree with the op:

> I don't see anything that indicates how spacetime solves the core problem CRDB does, which is guaranteeing that single node failures can be tolerated with zero data loss or loss of availability

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.

how would a single node system survive the failure of its only node?

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

you misunderstood me, I was responding to a2ff6eeb0 saying he agreed with the OP

I think people get hung up on high availability (HA), and ironically don't test their backups. Single node with streaming backups to S3 (simple in a single writer system) can give you a system that will at most lose a few seconds of data (interestingly RDS has a 5 minute window of dataloss).

Multi node systems tend to have more failure modes, so fail more often, high availability is not free.

If you replicate data between two nodes (that are note async backups). You have to maintain strong data consistency. So writes to the database are considered successful only if the data is written to both nodes. If either node became unavailable you'd be unable to write anything without sacrificing consistency, reducing our overall availability rather than improving it. Also increasing latency.

This is why the whole multi node HA push by the industry is so laughable. A lot of time it makes systems more fragile.

You don’t need CockroachDB for high availability though.

Sorry for spreading misinformation!

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

Reply on news.ycombinator.com