6 ms·

Ok, but does it scale?

Wilduck 12d ago
When did spacetimedb pivot from being a gamedev backend to being something for AI agents to use? Are they also trying to pivot to a IaaS model?
- Cthulhu_ 12d ago
  I don't know the answer so take this as a shitpost, but: investors and companies are throwing a lot of money in AI, not gamedev backends. AI reoriented companies are being sold with valuations in the billions.
- krisajenkins 7d ago
  I don't think they have pivoted. They're just realising there's nothing game-specific about the database they built for BitCraft, and they're widening the scope. The direction is more games-to-general-purpose than games-to-AI.
parasxos 12d ago
[dead]
randusername 12d ago
I had a coworker that would always ask this, like a javelin thrown in the bicycle spokes of every demo. We hoped for tens of users.
- gill-bates 12d ago
  I was waiting for a comment like this. It's not like there aren't any projects that should be thinking about "scale", but it's almost a meme at this point. There is even the section there near the beginning about how small web apps without many users 'may have to think about horizontal scaling as well' - no, no they don't. To take part in the meme as well, a single server with Postgres will suffice for what? 99% of companies?
  - convolvatron 12d ago
    its substantially worse than that. anytime anyone uses the word 'scale' without even saying what kind of scaling they mean is guilty of eroding the discourse. at this point I don't think we should even be talking about scaling without meaning 'the Amdahl residual'
    - cloutiertyler 12d ago
      Hear hear
  - nlawalker 12d ago
    Been a meme for a long time! Mongo DB is web scale https://www.youtube.com/watch?v=b2F-DItXtZs https://www.youtube.com/watch?v=b2F-DItXtZs
- anonzzzies 12d ago
  Yeah, I just always say 'it sure does!' ; not like people who make remarks like that will try / know how to try anyway. And if they do, even the largest prototypey crap we make can do 10-100x what sales/marketing expects (and they overshoot estimates always).
- to11mtm 12d ago
  It depends a bit on context... and scale of scale. At my first software engineering role the system I 'inherited' (The guy who wrote it quit after it launched, I was hired on after) was only used by 5-10 users at a time. On the flipside, one or two of those users would do things that the system was advertised as being able to do, but would really stress out the system and slow certain operations down for everyone, including exposing our company to financial penalty risks. We actually for a time slowed down trying to get large customers signed up, because even the business folks had to manage enough complaints that they didn't want to risk damage to our reputation. [0] At my second job, well, I remember the debate I had with the manager about a change I suggested to improve memory allocation on a new email templating process he wrote. He then gave me a lecture about 'premature optimization'. Then when the thing kept crashing with OOM errors he cribbed the parts of my changes that solved the memory leak but left out the pooled buffer to save face. [1] [0] - The thing was written such that we could only process 2 messages concurrently from a given integration partner at a time, we eventually fixed it by moving the processing to actors behind a consistent hash router. [1] - The pooled buffer changes were 5-10 extra lines total, lol.
AdamProut 12d ago
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.). Some SQL query operators are hard to scale out for OLTP queries that want low latency and high throughput (DISTINCT, LIMIT/TOP-N, non-collocated joins). I take it SpacetimeDB is a nosql database, so these problems are less important to them? As to how spacetimedb plans to scale out, I didn't follow it fully. It's hard to take the spacetimedb folks seriously (see: https://strn.cat/posts/spacetime/ https://strn.cat/posts/spacetime/).
- cloutiertyler 12d ago
  I'm a cofounder of SpacetimeDB (and the author of OPs article). The https://strn.cat/posts/spacetime/ 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 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.
  - chradams 12d ago
    It's absolutely wild that your post is flagged (downvoted). Thanks for writing the article and for replying here.
    - xnorswap 12d ago
      I didn't downvote, but I can understand it as a reaction to, "Ask claude yourself".
karldajabrony 12d ago
From what I understand, they are building out an MMO using spacetime. Sort of dogfooding it. Not saying that means it scales, but at least they will experience the painpoints just like anyone else using it
- pylotlight 12d ago
  Plus the hundreds of other users doing exactly the same thing, building games, tools, products with stdb which has been really cool to see. It's super cool tech imo. I made an obsidian sync plugin with it which was neat.
cropcirclbureau 12d ago
Me and Fable when the boss starts asking why my custom handrolled data engine needs to run on m6i.16xlarge for our 100 users.
- all2 12d ago
  For those who don't know (like me): https://instances.vantage.sh/aws/ec2/m6i.16xlarge?currency=USD https://instances.vantage.sh/aws/ec2/m6i.16xlarge?currency=U... This is a VM with 64 vCPUs running at 3.5GHz, with 256GB RAM. It presently costs about ~3USD per hour to run.
0skird 12d ago
[flagged]
djha-skin 12d ago
Ok, but does it need to scale?
- krisajenkins 7d ago
  That's a very fair question, and it got me thinking. So I wrote a full post answering it. But the short answer is, as long as you don't have to twist your architecture in knots to get high performance, then yes it's worth it. A system that can scale up, can also scale fast & cheap. https://spacetimedb.com/blog/okay-but-does-it-need-to-scale https://spacetimedb.com/blog/okay-but-does-it-need-to-scale
gandreani 12d ago
Nice! I like learning about databases but got a bit of "framework fatigue" when I started reading about all the number of dbs available today (and deciphering marketing from tech notes). This article hooked me with the comparison at the beginning. I used to scoff at redis' single threaded design but it makes sense in a memory bound db. This article is a great example of taking that high-performance approach and designing parallelization around it. SO COOOL. Also, it's SO interesting that here's yet another example of how performant the actor model can be. It's an old design (Communicating Sequential Processes was published in 1984!) but it works so well in our current hardware. From a developer's perspective actors are very easy to reason about. I'm curious to try out Spacetime in a project now. Organizing server logic into databases, sub-databases, tables and reducers is intriguing.
- krisajenkins 11d ago
  I totally agree. The thing that's drawing me to Spacetime is that it blends the processing model of actors and the data model of relational databases really neatly. Data comes in, do something with it, store your state in a principled way, repeat. Add in subscriptions to data and it becomes reactive. Simple.
themgt 12d ago
> 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.
- gefjon 12d ago
  SpacetimeDB is not Open Source Software. It is "source-available," but is a commercial product.
  - luhn 12d ago
    Interesting, it seems that it's Source Available but converts to Open Source (AGPL) in 2031. First time I've seen licensing like that. https://github.com/clockworklabs/SpacetimeDB/blob/master/LICENSE.txt https://github.com/clockworklabs/SpacetimeDB/blob/master/LIC...
    - odo1242 12d ago
      ml5.js has a similar license: https://github.com/ml5js/ml5-library?tab=License-1-ov-file https://github.com/ml5js/ml5-library?tab=License-1-ov-file Their license is basically "use freely unless our community decides you violated the code of conduct, for three years"
    - magicmicah85 12d ago
      The date keeps changing on each release so every version bump becomes AGPL five years from the date its published. Its an interesting model, but necessary to be aware of the nuance in case you ever want to consume it.
  - a2ff6eeb0 12d ago
    But given that it's vibe coded, it's probably in the public domain. Check with your lawyers :)
- deleted 12d ago
Rohansi 12d ago
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 https://spacetimedb.com/blog/benchmarking [2] https://x.com/spacetimedb/status/2027766319462904310 https://x.com/spacetimedb/status/2027766319462904310 [3] https://steamcharts.com/app/3454650 https://steamcharts.com/app/3454650
- 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 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.
  - 12d ago
whsoul 12d ago
In my service, I have used one of distributed DB, vitess from beginning. The problem was spending too many time for every time make table and shard key design to avoid placing a heavy load for DB with join, broadcast query, and so on. I’d like to recommend If you are really need to scale out soon, your domain is difficult to separated, only use distributed DB. It is true, distributed databases superior to many people technically, But that’s not mean they are better in your service situation I think it is better spend your time, separate domain architecture. Simply use DB. Do not put unpredictable future off DB as past Oracle DB handle all.
echohack5 12d ago
As someone who has been using alot of spacetime for side projects (like https://heat.echohack.app https://heat.echohack.app), I am continually impressed with the speed at which it operates. I think there's alot of interesting things happening in the database space. Vitess/Neki, vector stores, spacetime are all really good things to be happening. I think it's a shame that database developers seem to have a drama filled timeline out there. It's... all very exciting, together. Anyway, Some things that need improvement (some of which are addressed by this blog post): 1. Backups (fast recovery) and Disaster Recovery (slow, durable recovery) This is a big one, but sometimes speed is not the only objective you have to meet. You need to have certainty that, if everything goes down that you (eventually) can bring things back online. I don't really have a way of doing that today. 2. Read replicas sure would be nice for analytic workloads 3. Durable writes to s3 would be nice for intermittent bursting workloads (like ci systems) I think the Spacetime folks have their work cut out for them, not necessarily because of the technology (that's hard too) but because the AI models have seemingly decided that Neon and Postgres are all that exists. I think spacetime has a bright future ahead of it, and I am wishing the team all the best as they work hard to imprint something new on the universe.
ScottWilderHQ 12d ago
[dead]
timssopomo 12d ago
Spacetime sounds like really interesting technology, but I'm not sure that the comparison between CRDB is a good one. I used to work at Cockroach Labs. The problem it's solving is fundamentally different. CRDB as a solution makes sense when you need to _guarantee_ that transactions are serializable and durable, and that your application can survive node or region failures while maintaining consistency. In a naive deployment it's significantly slower than operating on a single core, but that's the price that you pay for the ability to survive node loss without data loss. 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. It sounds like transactions by default are required to be written to disk before completion, which makes them durable on a single node, but you can't ensure they're consistent across nodes without accepting the network overhead and losing transaction throughput (on writes, anyway). Also, FWIW, in the several years I worked covering basically every incident, I can't recall seeing a network-bound cluster. Like anything else, there are tradeoffs. You give throughput, you get consistency and availability, and you don't need to engineer how to avoid data loss or availability with node failures. Unless I'm misunderstanding, spacetime is solving a totally different problem.
- rockwotj 12d ago
  > 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/ 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.
  - 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 SpacetimeDB (and the author of OPs article). The https://strn.cat/posts/spacetime/ 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 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.
slopinthebag 12d ago
Previous discussion https://news.ycombinator.com/item?id=49378933 https://news.ycombinator.com/item?id=49378933
philippta 12d ago
I benchmarked Postgres in single- and muti-node setup against CockroachDB a while ago and my findings match what this post is talking about. https://github.com/philippta/postgresql-cockroachdb-benchmark https://github.com/philippta/postgresql-cockroachdb-benchmar...
chermi 12d ago
Off topic but... I had a friend who's main takeaway (tongue-in-check) from harvard mini-mba while he is in a SEAS program was that all you had to do to look smart around VC/tech-oriented business people was to ask this question. Then we actually founded a startup and realized this was not a silly question. But perhaps that's circular when the default path is VC funding, hmmm.
tpougy 12d ago
How does this compare to InstantDB [1] (which is sunsetting)? Both seem to achieve similar objectives and dev (ai dev) experience [1] https://www.instantdb.com/ https://www.instantdb.com/

When did spacetimedb pivot from being a gamedev backend to being something for AI agents to use? Are they also trying to pivot to a IaaS model?

Cthulhu_ 12d ago
I don't know the answer so take this as a shitpost, but: investors and companies are throwing a lot of money in AI, not gamedev backends. AI reoriented companies are being sold with valuations in the billions.
krisajenkins 7d ago
I don't think they have pivoted. They're just realising there's nothing game-specific about the database they built for BitCraft, and they're widening the scope. The direction is more games-to-general-purpose than games-to-AI.

parasxos 12d ago

[dead]

randusername 12d ago

I had a coworker that would always ask this, like a javelin thrown in the bicycle spokes of every demo. We hoped for tens of users.

gill-bates 12d ago
I was waiting for a comment like this. It's not like there aren't any projects that should be thinking about "scale", but it's almost a meme at this point. There is even the section there near the beginning about how small web apps without many users 'may have to think about horizontal scaling as well' - no, no they don't. To take part in the meme as well, a single server with Postgres will suffice for what? 99% of companies?
- convolvatron 12d ago
  its substantially worse than that. anytime anyone uses the word 'scale' without even saying what kind of scaling they mean is guilty of eroding the discourse. at this point I don't think we should even be talking about scaling without meaning 'the Amdahl residual'
  - cloutiertyler 12d ago
    Hear hear
- nlawalker 12d ago
  Been a meme for a long time! Mongo DB is web scale https://www.youtube.com/watch?v=b2F-DItXtZs https://www.youtube.com/watch?v=b2F-DItXtZs
anonzzzies 12d ago
Yeah, I just always say 'it sure does!' ; not like people who make remarks like that will try / know how to try anyway. And if they do, even the largest prototypey crap we make can do 10-100x what sales/marketing expects (and they overshoot estimates always).
to11mtm 12d ago
It depends a bit on context... and scale of scale. At my first software engineering role the system I 'inherited' (The guy who wrote it quit after it launched, I was hired on after) was only used by 5-10 users at a time. On the flipside, one or two of those users would do things that the system was advertised as being able to do, but would really stress out the system and slow certain operations down for everyone, including exposing our company to financial penalty risks. We actually for a time slowed down trying to get large customers signed up, because even the business folks had to manage enough complaints that they didn't want to risk damage to our reputation. [0] At my second job, well, I remember the debate I had with the manager about a change I suggested to improve memory allocation on a new email templating process he wrote. He then gave me a lecture about 'premature optimization'. Then when the thing kept crashing with OOM errors he cribbed the parts of my changes that solved the memory leak but left out the pooled buffer to save face. [1] [0] - The thing was written such that we could only process 2 messages concurrently from a given integration partner at a time, we eventually fixed it by moving the processing to actors behind a consistent hash router. [1] - The pooled buffer changes were 5-10 extra lines total, lol.

AdamProut 12d ago

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.). Some SQL query operators are hard to scale out for OLTP queries that want low latency and high throughput (DISTINCT, LIMIT/TOP-N, non-collocated joins). I take it SpacetimeDB is a nosql database, so these problems are less important to them? As to how spacetimedb plans to scale out, I didn't follow it fully. It's hard to take the spacetimedb folks seriously (see: https://strn.cat/posts/spacetime/ https://strn.cat/posts/spacetime/).

cloutiertyler 12d ago
I'm a cofounder of SpacetimeDB (and the author of OPs article). The https://strn.cat/posts/spacetime/ 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 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.
- chradams 12d ago
  It's absolutely wild that your post is flagged (downvoted). Thanks for writing the article and for replying here.
  - xnorswap 12d ago
    I didn't downvote, but I can understand it as a reaction to, "Ask claude yourself".

karldajabrony 12d ago

From what I understand, they are building out an MMO using spacetime. Sort of dogfooding it. Not saying that means it scales, but at least they will experience the painpoints just like anyone else using it

pylotlight 12d ago
Plus the hundreds of other users doing exactly the same thing, building games, tools, products with stdb which has been really cool to see. It's super cool tech imo. I made an obsidian sync plugin with it which was neat.

cropcirclbureau 12d ago

Me and Fable when the boss starts asking why my custom handrolled data engine needs to run on m6i.16xlarge for our 100 users.

all2 12d ago
For those who don't know (like me): https://instances.vantage.sh/aws/ec2/m6i.16xlarge?currency=USD https://instances.vantage.sh/aws/ec2/m6i.16xlarge?currency=U... This is a VM with 64 vCPUs running at 3.5GHz, with 256GB RAM. It presently costs about ~3USD per hour to run.

0skird 12d ago

[flagged]

djha-skin 12d ago

Ok, but does it need to scale?

krisajenkins 7d ago
That's a very fair question, and it got me thinking. So I wrote a full post answering it. But the short answer is, as long as you don't have to twist your architecture in knots to get high performance, then yes it's worth it. A system that can scale up, can also scale fast & cheap. https://spacetimedb.com/blog/okay-but-does-it-need-to-scale https://spacetimedb.com/blog/okay-but-does-it-need-to-scale

gandreani 12d ago

Nice! I like learning about databases but got a bit of "framework fatigue" when I started reading about all the number of dbs available today (and deciphering marketing from tech notes). This article hooked me with the comparison at the beginning. I used to scoff at redis' single threaded design but it makes sense in a memory bound db. This article is a great example of taking that high-performance approach and designing parallelization around it. SO COOOL. Also, it's SO interesting that here's yet another example of how performant the actor model can be. It's an old design (Communicating Sequential Processes was published in 1984!) but it works so well in our current hardware. From a developer's perspective actors are very easy to reason about. I'm curious to try out Spacetime in a project now. Organizing server logic into databases, sub-databases, tables and reducers is intriguing.

krisajenkins 11d ago
I totally agree. The thing that's drawing me to Spacetime is that it blends the processing model of actors and the data model of relational databases really neatly. Data comes in, do something with it, store your state in a principled way, repeat. Add in subscriptions to data and it becomes reactive. Simple.

themgt 12d ago

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

gefjon 12d ago
SpacetimeDB is not Open Source Software. It is "source-available," but is a commercial product.
- luhn 12d ago
  Interesting, it seems that it's Source Available but converts to Open Source (AGPL) in 2031. First time I've seen licensing like that. https://github.com/clockworklabs/SpacetimeDB/blob/master/LICENSE.txt https://github.com/clockworklabs/SpacetimeDB/blob/master/LIC...
  - odo1242 12d ago
    ml5.js has a similar license: https://github.com/ml5js/ml5-library?tab=License-1-ov-file https://github.com/ml5js/ml5-library?tab=License-1-ov-file Their license is basically "use freely unless our community decides you violated the code of conduct, for three years"
  - magicmicah85 12d ago
    The date keeps changing on each release so every version bump becomes AGPL five years from the date its published. Its an interesting model, but necessary to be aware of the nuance in case you ever want to consume it.
- a2ff6eeb0 12d ago
  But given that it's vibe coded, it's probably in the public domain. Check with your lawyers :)
deleted 12d ago

Rohansi 12d ago

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 https://spacetimedb.com/blog/benchmarking [2] https://x.com/spacetimedb/status/2027766319462904310 https://x.com/spacetimedb/status/2027766319462904310 [3] https://steamcharts.com/app/3454650 https://steamcharts.com/app/3454650

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 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.
- 12d ago

whsoul 12d ago

In my service, I have used one of distributed DB, vitess from beginning. The problem was spending too many time for every time make table and shard key design to avoid placing a heavy load for DB with join, broadcast query, and so on. I’d like to recommend If you are really need to scale out soon, your domain is difficult to separated, only use distributed DB. It is true, distributed databases superior to many people technically, But that’s not mean they are better in your service situation I think it is better spend your time, separate domain architecture. Simply use DB. Do not put unpredictable future off DB as past Oracle DB handle all.

echohack5 12d ago

As someone who has been using alot of spacetime for side projects (like https://heat.echohack.app https://heat.echohack.app), I am continually impressed with the speed at which it operates. I think there's alot of interesting things happening in the database space. Vitess/Neki, vector stores, spacetime are all really good things to be happening. I think it's a shame that database developers seem to have a drama filled timeline out there. It's... all very exciting, together. Anyway, Some things that need improvement (some of which are addressed by this blog post): 1. Backups (fast recovery) and Disaster Recovery (slow, durable recovery) This is a big one, but sometimes speed is not the only objective you have to meet. You need to have certainty that, if everything goes down that you (eventually) can bring things back online. I don't really have a way of doing that today. 2. Read replicas sure would be nice for analytic workloads 3. Durable writes to s3 would be nice for intermittent bursting workloads (like ci systems) I think the Spacetime folks have their work cut out for them, not necessarily because of the technology (that's hard too) but because the AI models have seemingly decided that Neon and Postgres are all that exists. I think spacetime has a bright future ahead of it, and I am wishing the team all the best as they work hard to imprint something new on the universe.

ScottWilderHQ 12d ago

[dead]

timssopomo 12d ago

Spacetime sounds like really interesting technology, but I'm not sure that the comparison between CRDB is a good one. I used to work at Cockroach Labs. The problem it's solving is fundamentally different. CRDB as a solution makes sense when you need to _guarantee_ that transactions are serializable and durable, and that your application can survive node or region failures while maintaining consistency. In a naive deployment it's significantly slower than operating on a single core, but that's the price that you pay for the ability to survive node loss without data loss. 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. It sounds like transactions by default are required to be written to disk before completion, which makes them durable on a single node, but you can't ensure they're consistent across nodes without accepting the network overhead and losing transaction throughput (on writes, anyway). Also, FWIW, in the several years I worked covering basically every incident, I can't recall seeing a network-bound cluster. Like anything else, there are tradeoffs. You give throughput, you get consistency and availability, and you don't need to engineer how to avoid data loss or availability with node failures. Unless I'm misunderstanding, spacetime is solving a totally different problem.

rockwotj 12d ago
> 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/ 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.
- 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 SpacetimeDB (and the author of OPs article). The https://strn.cat/posts/spacetime/ 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 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.

slopinthebag 12d ago

Previous discussion https://news.ycombinator.com/item?id=49378933 https://news.ycombinator.com/item?id=49378933

philippta 12d ago

I benchmarked Postgres in single- and muti-node setup against CockroachDB a while ago and my findings match what this post is talking about. https://github.com/philippta/postgresql-cockroachdb-benchmark https://github.com/philippta/postgresql-cockroachdb-benchmar...

chermi 12d ago

Off topic but... I had a friend who's main takeaway (tongue-in-check) from harvard mini-mba while he is in a SEAS program was that all you had to do to look smart around VC/tech-oriented business people was to ask this question. Then we actually founded a startup and realized this was not a silly question. But perhaps that's circular when the default path is VC funding, hmmm.

tpougy 12d ago

How does this compare to InstantDB [1] (which is sunsetting)? Both seem to achieve similar objectives and dev (ai dev) experience [1] https://www.instantdb.com/ https://www.instantdb.com/