SpacetimeDB lays out its scaling story, with horizontal storage due October 31

SpacetimeDB has published a long-form engineering post answering the question its author says comes up more than any other about the database: does it scale? The piece, titled "Ok, but Does It Scale?", appeared on the Spacetime blog on September 4, 2026 and was picked up on Hacker News's front page. Rather than offering a simple yes, the post argues the question itself is underspecified, works through scalability from first principles, and then measures Postgres, Neon and CockroachDB against that framework before stating what Spacetime itself will ship.

Three independent axes of scale

The post first separates vertical scaling — getting more from one bigger machine — from horizontal scaling, where doubling the machines roughly doubles the work. Most people who ask about scalability mean the horizontal kind, the author notes, since a single computer has hard limits while machines can in principle be added indefinitely. But a yes-or-no answer misses the point, because scalability splits into three largely independent dimensions: compute, meaning how many transactions a system can process; storage, meaning how much data it can hold; and networking, meaning how many connections and how much bandwidth it can sustain. A database can scale along one axis and fail on the others, and the post uses three PostgreSQL-compatible systems with very different architectures to show how.

Postgres, Neon and CockroachDB, compared

Postgres, according to the post, is essentially a single-node system: it has no concept of a cluster of primaries, cannot run transactions across instances, and only scales reads if you manually deploy replicas, which come with read-after-write consistency caveats. Neon, a modified Postgres variant, horizontally scales storage by backing tables with object storage behind a local page cache, letting even small applications accumulate very large datasets — though cache misses cost latency and all writes still funnel through a single primary. CockroachDB, which the author treats as a stand-in for general-purpose distributed relational systems like Spanner and Aurora DSQL and repeatedly credits as remarkable engineering, divides each table into ranges spread across the cluster, each typically replicated to two additional machines. Its architecture is symmetric — every node can handle any SQL request, reads or writes — and it scales computation that parallelizes cleanly, such as analytics or writes to unrelated keys.

The cost of coordination

The core of the argument is that no system escapes the limits of parallel computing. When transactions contend for the same data, updates happen one at a time regardless of how many machines you own, yet a CockroachDB-style design still charges every transaction the full price of distributed coordination. The post illustrates this with a stark example: work one machine completes in a millisecond can take ten machines a hundred milliseconds once coordination is factored in. Two structural problems are identified. First, because data ownership is spread evenly around the cluster, the rows a transaction touches are rarely co-located, so nearly every transaction pays network round trips. Second, no transaction gets exclusive access to a range, so all transactions bear distributed concurrency-control overhead while conflicting ones must wait, abort or retry. The post notes that Spanner's table interleaving, which co-locates related tables, partially mitigates the first problem.

What Spacetime is committing to

For Spacetime's own roadmap, the post's summary gives a concrete date: horizontally scaled storage ships October 31, 2026, which the author calls the relatively straightforward part. Compute and networking, by contrast, cannot all be scaled horizontally in the general case. The company's pitch is that Spacetime maintains high performance under contention — precisely where the post claims general-purpose distributed OLTP databases degrade — while giving developers tools to scale the OLTP workloads that genuinely do parallelize.

Why it matters

Scaling is the reflex objection to any new database, and this post replaces a binary answer with a framework — compute, storage, networking — that architects can apply to any system, competitors included. The contention critique is also a practical consideration for teams choosing between a single primary and distributed SQL: coordination costs are paid on every transaction, including ones that would have been serialized anyway. Finally, the October 31 storage date turns an architectural argument into a verifiable milestone. Whether Spacetime's performance holds up under genuinely contended workloads is what will ultimately answer the question in its title.