SpacetimeDB has published a long technical essay that tries to answer a question every infrastructure company eventually faces: does it scale?
The post, titled “Ok, but does it scale?”, argues that the word is too vague to be useful unless it is broken into three separate dimensions: compute, storage and networking. That framing is the foundation of the essay’s answer about SpacetimeDB itself. The company says storage can be scaled horizontally relatively cleanly, but that compute and networking are a different problem, especially when transactions contend with one another.
The essay draws a sharp distinction between systems that can do more work with more machines and systems that simply add coordination overhead. It says some general-purpose horizontally distributed databases promise scale but perform badly when many transactions touch the same data. In those cases, the cost of coordination can outweigh the benefits of spreading work across the cluster. The post uses familiar examples such as Postgres, Neon, Spanner and CockroachDB to explain the trade-offs, while stressing that each of those systems is still an impressive engineering achievement.
A central claim is that contention is the enemy of naive horizontal scaling. If many clients need to update the same rows or the same logical object, the system has to coordinate who owns what and which version is valid. The essay says that can force work that looks parallel on paper to become sequential in practice. That is why, in its telling, scaling a database is not just a matter of adding nodes. It is a matter of understanding whether the workload can actually be split into pieces that different computers can process at the same time.
The article also spends time on architectural examples. It argues that Neon’s design gives users effectively infinite storage because data can live in object storage, but that writes still pass through a primary. It says Spanner’s table interleaving can help colocate related data, while CockroachDB’s earlier support for the same technique was eventually removed as too complex for the benefit it delivered. The point is not that one database “wins” and another “loses” in every case. It is that each system scales differently, and the right choice depends on workload shape.
SpacetimeDB says its own approach is to make parallelizable OLTP workloads easier to scale while preserving performance under contention. That is a narrower promise than some distributed databases make, but it is also more honest about what real software can and cannot do. The essay argues that scalability is often sold as an almost magical property, when in practice it is a collection of engineering compromises, each with a cost attached.
For builders, that is the useful takeaway. If your workload is mostly independent reads or writes, storage and compute can often be spread out. If your workload concentrates on shared objects, counters or hot rows, you can spend a lot of money and still get worse results than a smaller, simpler system. The essay’s argument is that those trade-offs should be explicit up front, not discovered after the production bill arrives.
The result is part product essay, part database primer. It explains why “does it scale?” is the wrong question on its own and why serious teams should ask what, exactly, is scaling: storage, compute, networking, or all three. SpacetimeDB’s answer is that the distinction matters because most systems do not scale evenly, and pretending otherwise is how architecture debt gets expensive.
