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

▲

cloutiertyler 4 days ago | parent | next [-]

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.

▲

AdamProut 4 days ago | parent | next [-]

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.

▲

cloutiertyler 4 days ago | parent [-]

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

▲

djha-skin 4 days ago | parent [-]

Fresh reader here. I am very interested to learn more about your sentence

> We spent a lot of money finding out that a lock is more performant.

I want to hear about that journey.

> Besides, it's a btree.

I guess it's not a hash table, but I think the point of Vincent's post is still worth exploring. You and he both say that essentially a key/value store is mutexed, and the user's code runs inside that mutex. That is fascinating. Why would that be better? Clearly it is, or you wouldn't have spent the money. What controls did you put in place to ensure user code didn't blow up the performance, or did you even feel the need for such controls? Is WASM VM execution fast enough for this? Is there even a market for that? Who pays to put their code inside that mutex and why? I want to know more.

▲

cloutiertyler 4 days ago | parent [-]

I don't have the whole story for you, but the key is that SpacetimeDB transactions are not interactive. The TigerBeetle team talks about this a lot as well.

The TL;DR is that because you're not holding locks across the network (as is the case in Postgres), your server code can complete transactions in single digit microseconds, rather than milliseconds. And the practical effect is you can do many more transactions per second as a result.

▲

senkora 4 days ago | parent [-]

Would it be correct to say that this is an example of the “Actually Serial Execution” strategy for implementing serializable transactions in the terminology of “Designing Data Intensive Applications”?

(I mention this mainly as a keyword that people can look up for more information)

	▲	cloutiertyler 3 days ago \| parent [-]
		Yep, that’s exactly what it is.

▲

conormccarter 4 days ago | parent | prev | next [-]

> 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

	▲	cloutiertyler 4 days ago \| parent [-]
		I'm aware of his work on git, and that is not a database storage engine.

▲

xnorswap 4 days ago | parent | prev | next [-]

What do you mean by "acknowledge", and is that same level of acknowledgement the level used in benchmarks?

	▲	cloutiertyler 4 days ago \| parent [-]
		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

▲

chradams 4 days ago | parent | prev [-]

It's absolutely wild that your post is flagged (downvoted). Thanks for writing the article and for replying here.

▲

xnorswap 4 days ago | parent [-]

I didn't downvote, but I can understand it as a reaction to, "Ask claude yourself".

	▲	cloutiertyler 4 days ago \| parent [-]
		I know people aren't going to put more than a few minutes into verification, so that's why I suggested it. I'm not really sure what else to do. It really is all there in the code.

▲

vrosas 4 days ago | parent | prev [-]

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.

▲

cloutiertyler 4 days ago | parent | next [-]

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?

	▲	roncesvalles 4 days ago \| parent [-]
		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).

▲

AdamProut 4 days ago | parent | prev [-]

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.

	▲	vrosas 4 days ago \| parent [-]
		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?