Comment by AdamProut
2 days 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/).
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.
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.
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).
4 replies →
> 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.
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
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".
1 reply →
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.
Is it really not more expensive? I haven't operated a large scale Spanner cluster, but the numbers would suggest it's quite a bit more expensive. I suppose it's workload dependent is what you're saying?
I ran some rough numbers a while ago and I found single-region GCP Spanner to be the most cost-effective relational DB option (out of the ones I looked it) if you don't mind that it can't scale to zero (min $65/mo), if synchronous replication for durability is a must and you need serializability. It's more cost effective than any Aurora offering including DSQL (which isn't serializable afaik but even then).
what kind of maintenance?
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.
Major version upgrades, HA, multi-master, sharding and georeplication are all stories that are not as out-of-the box simple as they should be at this point, IMHO. Then you layer on all the ways devs tend to abuse postgres (stored procedures, pubsub systems, re-indexing hot tables, etc) that will need hours and hours of debate + meetings + committees + design reviews + more meetings to settle. When all along the team probably could have just written the data to something like Firestore and been, like, totally fine?