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.
> 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.
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/).
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 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.
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.
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.
I think one of the maybe less talked about benefits of distributed SQL is support for nearly transparent rolling upgrades of the database with very little impact to a running workload. Spanner is best in class at this.
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.
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?
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).
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.
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
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.
> 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
> 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.
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/).
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
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.
The guy is currently a micro-celebrity for the storage engine he wrote: https://cursor.com/blog/git-at-any-scale
I have doubts that a global readwrite lock around a hashtable makes for a good general purpose storage system.
- 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
I think one of the maybe less talked about benefits of distributed SQL is support for nearly transparent rolling upgrades of the database with very little impact to a running workload. Spanner is best in class at this.
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.
This is a VM with 64 vCPUs running at 3.5GHz, with 256GB RAM.
It presently costs about ~3USD per hour to run.
We hoped for tens of users.