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've pushed teams to choose Spanner over using Postgres (when already in the GCP ecosystem). It's not really more expensive when you sit down and do the math, you save untold hours of maintenance over the lifespan of the app, and it actually scales without fuss.
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?
I ran some rough numbers a while ago and I found single-region GCP Spanner to be the most cost-effective relational DB option (out of the ones I looked it) if you don't mind that it can't scale to zero (min $65/mo), if synchronous replication for durability is a must and you need serializability. It's more cost effective than any Aurora offering including DSQL (which isn't serializable afaik but even then).
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.
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
how would a single node system survive the failure of its only node?
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
how would a single node system survive the failure of its only node?
> You get to deploy your server logic directly into the database > You may make use of the Licensed Work provided your application or service uses the Licensed Work with no more than one SpacetimeDB instance in production and provided that you do not use the Licensed Work for a Database Service. Therefore, as an OSS product, SpacetimeDB does not scale.
SpacetimeDB is not Open Source Software. It is "source-available," but is a commercial product.
But given that it's vibe coded, it's probably in the public domain. Check with your lawyers :)
Yes, the irony is that vertically scaling will always go "faster" due to latency until you genuinely need more DB than a single box can handle. Premature horizontal scaling only increase complexity and reduce performance. And even when you genuinely need it the implementation has to fight merely to approach single box latency, which sounds like what these guys have done. But also vertical scaling seems to be able to…
> I suspect we will eventually end up in a place where the vast majority of applications are happy on a single box, and only twitter scale things need to care about this stuff. We're already there IMO. A single box can scale up so much more than people expect these days - over a thousand cores and terabytes of RAM. The people coming up with overcomplicated architectures and mandatory high availability get in the way…
A single box may have that much resources available, but no software will use them efficiently alone. You end up having issues with NUMA, with your pagetable growing significantly forcing you to deal with hugepages and eventually memory fragmentation, and who knows what other kind of lovecraftian horror coming from the sheer complexity of a single system with that much resources. Turns out scaling vertically also has cost. That's why eventually you still want to scale horizontally. And that's not overcomplicating things for the fun of it, it's just tradeoffs.
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
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.
> 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…
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, almos…