Ok, but Does It Scale?

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

As someone who has been using alot of spacetime for side projects (like 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.

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

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

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

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.

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.

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.

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?

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

Ok, but does it need to scale?

[dead]

[flagged]

[dead]