3 ms·

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

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.

a2ff6eeb0 29d ago
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
- cloutiertyler 29d ago
  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.
- andersonpico 29d ago
  how would a single node system survive the failure of its only node?
  - deleted 29d ago
    [deleted]
  - cloutiertyler 29d ago
    It wouldn’t. SpacetimeDB Cloud is not single node. And before you say it’s not open source, neither is CRDB.
    - andersonpico 27d ago
      you misunderstood me, I was responding to a2ff6eeb0 saying he agreed with the OP
andersmurphy 29d ago
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.
- cloutiertyler 28d ago
  You don’t need CockroachDB for high availability though.

a2ff6eeb0 29d ago

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

cloutiertyler 29d ago
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.
andersonpico 29d ago
how would a single node system survive the failure of its only node?
- deleted 29d ago
  [deleted]
- cloutiertyler 29d ago
  It wouldn’t. SpacetimeDB Cloud is not single node. And before you say it’s not open source, neither is CRDB.
  - andersonpico 27d ago
    you misunderstood me, I was responding to a2ff6eeb0 saying he agreed with the OP

andersmurphy 29d ago

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.

cloutiertyler 28d ago
You don’t need CockroachDB for high availability though.