Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ok, but does it scale?

spacetimedb.com

Post reply on HN
Print view View original

21–30 of 76 posts

Re: Ok, but does it scale?

#21

Post by xnorswap »

chradams wrote: post #13
cloutiertyler wrote: post #10

Earlier quoted context omitted.

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 y…

It's absolutely wild that your post is flagged (downvoted). Thanks for writing the article and for replying here.

I didn't downvote, but I can understand it as a reaction to, "Ask claude yourself".

Re: Ok, but does it scale?

#22

Post by conormccarter »

cloutiertyler wrote: post #10
AdamProut wrote: post #5

The intro section is a good summary of why distributed SQL databases (Spanner, roach, Yugabyte, TiDB) haven't taken off in the market in the same way as say distributed data warehouses have (Snowflake, Databricks, FabricDW, Clickhouse, etc.). I would add a few other things to the list of scaling problems. Some SQL features are hard to scale out (auto_increment/serial columns, unique secondary keys, foreign keys, etc.…

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 y…

> having never written a storage engine before AFAIK

The guy is currently a micro-celebrity for the storage engine he wrote: https://cursor.com/blog/git-at-any-scale

Re: Ok, but does it scale?

#23

Post by AdamProut »

cloutiertyler wrote: post #10
AdamProut wrote: post #5

The intro section is a good summary of why distributed SQL databases (Spanner, roach, Yugabyte, TiDB) haven't taken off in the market in the same way as say distributed data warehouses have (Snowflake, Databricks, FabricDW, Clickhouse, etc.). I would add a few other things to the list of scaling problems. Some SQL features are hard to scale out (auto_increment/serial columns, unique secondary keys, foreign keys, etc.…

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 y…

I'll admit to not reading your code. It's hard to keep up with all the different databases launched in the last decade.

I have doubts that a global readwrite lock around a hashtable makes for a good general purpose storage system.

Re: Ok, but does it scale?

#24

Post by themgt »

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

Re: Ok, but does it scale?

#25

Post by cloutiertyler »

conormccarter wrote: post #22
cloutiertyler wrote: post #10

Earlier quoted context omitted.

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 y…

> having never written a storage engine before AFAIK The guy is currently a micro-celebrity for the storage engine he wrote: https://cursor.com/blog/git-at-any-scale

I'm aware of his work on git, and that is not a database storage engine.

Re: Ok, but does it scale?

#26

Post by cloutiertyler »

xnorswap wrote: post #20
cloutiertyler wrote: post #10

Earlier quoted context omitted.

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 y…

What do you mean by "acknowledge", and is that same level of acknowledgement the level used in benchmarks?

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

Re: Ok, but does it scale?

#27

Post by cloutiertyler »

xnorswap wrote: post #21
chradams wrote: post #13

Earlier quoted context omitted.

It's absolutely wild that your post is flagged (downvoted). Thanks for writing the article and for replying here.

I didn't downvote, but I can understand it as a reaction to, "Ask claude yourself".

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.

Re: Ok, but does it scale?

#28

Post by Rohansi »

While I think the tech is cool, and I'm sure it is fast, the fact that the benchmarks make assumptions about your stack doesn't sit right with me. They even admit that it is the main contributor to its speed:

> The most significant (but not sole) reason SpacetimeDB is faster than other backends is that we have decreased the round trip time between your server and your database by at least 99.95%. In SpacetimeDB your application server, ORM, and database are merged into a single system, so all three of these are run within the same process. [1]

For most systems that is a fair assumption to make but SQLite blurs the lines by running in-process. They admitted that this makes a significant difference on X [2] but do not list those results on their benchmarks. It would ruin their "is that the X axis or is that the competition" line to include. I'm hung up on this because they market it for use in video game servers, with an emphasis on MMORPGs (they're making one). Literally nobody is using web APIs for networking in real-time multiplayer games. The benchmarks are completely meaningless for that use case.

On the topic of scale they have been testing sharding/IDC for a while in BitCraft Online (their MMORPG) but they peaked at less than 5,000 concurrent players [3]. That's small enough to comfortably run on a single machine. Especially if you know that their gameplay is 90% (or more) just waiting on timers to finish. The timers only progress when you're connected to the server so that CCU number includes all the players waiting on timers.

[1] https://spacetimedb.com/blog/benchmarking [2] https://x.com/spacetimedb/status/2027766319462904310 [3] https://steamcharts.com/app/3454650

Re: Ok, but does it scale?

#29

Post by cloutiertyler »

AdamProut wrote: post #23
cloutiertyler wrote: post #10

Earlier quoted context omitted.

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 y…

I'll admit to not reading your code. It's hard to keep up with all the different databases launched in the last decade. I have doubts that a global readwrite lock around a hashtable makes for a good general purpose storage system.

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

Re: Ok, but does it scale?

#30

Post by cloutiertyler »

Rohansi wrote: post #28

While I think the tech is cool, and I'm sure it is fast, the fact that the benchmarks make assumptions about your stack doesn't sit right with me. They even admit that it is the main contributor to its speed: > The most significant (but not sole) reason SpacetimeDB is faster than other backends is that we have decreased the round trip time between your server and your database by at least 99.95%. In SpacetimeDB your…

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.

Post reply on HN