cloutiertyler

6 ms·

1.
by cloutiertyler 11d ago
Yep, that’s exactly what it is.
2.
by cloutiertyler 11d ago
Hardly your fault! It’s the responsibility of the person writing the article to do the technical diligence. Nevertheless did want to address it.
3.
by cloutiertyler 11d ago
You don’t need CockroachDB for high availability though.
4.
by cloutiertyler 12d ago
It wouldn’t. SpacetimeDB Cloud is not single node. And before you say it’s not open source, neither is CRDB.
5.
by cloutiertyler 12d 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.
6.
by cloutiertyler 12d ago
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.
7.
by cloutiertyler 12d ago
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?
8.
by cloutiertyler 12d ago
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 Sp
9.
by cloutiertyler 12d ago
> 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 failur
10.
by cloutiertyler 12d ago
Hear hear
11.
by cloutiertyler 12d ago
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
12.
by cloutiertyler 12d ago
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 bench
13.
by cloutiertyler 12d ago
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"
14.
by cloutiertyler 12d ago
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.
15.
by cloutiertyler 12d ago
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
16.
by cloutiertyler 12d ago
I'm aware of his work on git, and that is not a database storage engine.
17.
by cloutiertyler 12d ago
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, al
18.
by cloutiertyler 24d ago
You're just describing OLTP transactions, which is exactly what OLTP benchmarks are designed to test.
19.
by cloutiertyler 24d ago
Vicent claimed our database wasn't ACID. I would not say the tone of it is especially even handed, and the technical accuracy of it borders on libel.
20.
by cloutiertyler 24d ago
I'm publishing a post this week about it.
21.
by cloutiertyler 24d ago
That was indeed our reasoning. SpacetimeDB is largely prerequisite for the game we had to build.
22.
by cloutiertyler 26d ago
Yes, of course it did. This article makes factually wrong claims about the database I've spent 6+ years building. Your comment was about whether SpacetimeDB was "just a hashmap behind a RwLock" and the blog post I linked addr
23.
by cloutiertyler 26d ago
I don't really have a deep technical explanation blog post out, but we should definitely publish one. I can say that your last paragraph is essentially correct though. It works exactly that way.
24.
by cloutiertyler 26d ago
On the contrary, even the writer of this blog post told me that BitCraft is "a very enjoyable game"!
25.
by cloutiertyler 26d ago
Extraordinary claims perhaps, but correct ones nevertheless: https://spacetimedb.com/blog/benchmarking . The article says that we don't provide strong durability guarantees. Pure ipse dixit. And IIRC he's alre
26.
by cloutiertyler 26d ago
As a SpacetimeDB dev, I absolutely agree. However, these benchmarks are more than fair. Please read our full technical writeup on the benchmarks: https://spacetimedb.com/blog/benchmarking
27.
by cloutiertyler 26d ago
Since we're asking clankers: https://chatgpt.com/c/6a886e34-c784-83ea-8298-2d8215f5994a https://claude.ai/share/658d00e4-550a-470e-b4a3-7a71a06222cb > In particular, these statements shoul
28.
by cloutiertyler 26d ago
I would encourage you to read our technical blog post in reply to this article: https://spacetimedb.com/blog/benchmarking
29.
by cloutiertyler 26d ago
I would encourage you to read our technical write up in reply to this article: https://spacetimedb.com/blog/benchmarking
30.
by cloutiertyler 26d ago
I think you mean it sounds as good as the article says it is. SpacetimeDB is single threaded by design, just like TigerBeetle by the way. The reason we changed from MVCC to single threaded design is that it's simply faster for almost

More ›