11–20 of 76 posts
Me and Fable when the boss starts asking why my custom handrolled data engine needs to run on m6i.16xlarge for our 100 users.
This is a VM with 64 vCPUs running at 3.5GHz, with 256GB RAM.
It presently costs about ~3USD per hour to run.
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…
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.…
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
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?
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'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.
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.
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…