Ok, but does it scale?

By Tyler Cloutier | Posted September 3rd, 2026

Of all the inquiries I receive regarding Spacetime, this is likely the most frequent. While it seems like a straightforward question that should elicit a simple "yes" or "no," the reality is that scaling is a nuanced topic where the specific details matter immensely.

That said, we can still demystify the concept of scalability by breaking it down to its first principles.

The Quick Summary

If you are looking for the short concise version, here is the state of play:

• Compute: Scaling depends on the workload (parallelizable vs. contending).
• Storage: Horizontal scaling is coming on October 31st, 2026.
• Networking: Essential for handling connection volume and bandwidth.

Crucial Distinction: While many OLTP databases claim universal horizontal scalability, they often suffer from massive overhead per transaction and collapse under high contention. Spacetime is engineered to maintain high performance during contention while providing the tools to scale parallel workloads.

Note: When I mention CockroachDB, I am using it as a proxy for most general-purpose, horizontally scaling RDBMSs, including Google Spanner and Aurora DSQL. These are all magnificent engineering achievements, despite the limitations I will discuss.

---

Understanding "Scale" Intuitively

Most people have a visceral sense of what "scaling" means. It's the ability to support a billion users, handle "infinite" data, or grow a business by $10\times$ or $100\times$ annually without having to scrap the entire codebase and start over.

Usually, this conversation centers on the difference between Vertical and Horizontal scaling:

1. Vertical Scaling: Increasing the power of a single machine (more RAM, faster CPU).
2. Horizontal Scaling: Increasing the number of machines in the system.

In a perfectly scalable horizontal system, the relationship can be expressed as: $\text{Work Capacity} \propto \text{Number of Nodes}$ Or more simply: if you double the hardware, you should roughly double the throughput. Since there is a physical ceiling on how large a single computer can be, but no theoretical limit on how many computers you can buy, horizontal scaling is the "holy grail" of system design.

NOTE: While all horizontally scalable systems are distributed systems, not all distributed systems exist to scale. For instance, distributed state machine replication focuses on redundancy and reliability (doing the same work on multiple machines) rather than increasing total capacity.

---

The Three Dimensions of Scalability

Asking "Does it scale horizontally?" is too vague. To get a real answer, we must ask: "In which dimensions does it scale?" There are three primary, independent vectors:

1. Compute: The capacity to process transactions.
2. Storage: The total volume of data the system can hold.
3. Networking: The ability to handle concurrent connections and data throughput.

(These are the same "foundational ingredients" highlighted in our 1.0 announcement keynote.)

---

Comparative Analysis: Postgres-Compatible Systems

To illustrate these dimensions, let's look at three different architectures that all provide PostgreSQL interfaces.

1. Standard Postgres

Postgres is primarily a single-node system. It does not natively scale compute, storage, or networking horizontally.

• The Workaround: You can deploy multiple instances, but the database itself is unaware of them.
• Read Replicas: You can manually route read-only traffic to replicas to help with compute and networking, but this introduces risks regarding read-after-write consistency.
• The Result: Scaling Postgres horizontally is essentially "left as an exercise to the reader."

2. Neon

Neon is a modified Postgres variant that solves the Storage problem.

• Architecture: It uses object storage backed by a local page caching system.
• Benefit: This provides virtually infinite storage capacity.
• Limitation: Compute and networking are not automatically scaled; all writes must still hit a single primary node.

3. CockroachDB (and Spanner)

These systems aim to scale across all three dimensions.

• Storage: Data is split into "ranges" and distributed across the cluster, with each range typically replicated three times.
• Networking: They use a symmetric architecture where any node can handle any SQL request.
• Compute: If the workload is parallel (e.g., analytics or writes to different keys), it scales horizontally.

Summary Comparison Table

*Scales compute primarily for non-contending workloads.

To implement a basic check for scaling logic in a hypothetical system, one might use a structure like this:

fn check_scaling_dimension(dimension: Dimension) -> bool {
    match dimension {
        Dimension::Storage => true, // Coming Oct 31
        Dimension::Networking => true,
        Dimension::Compute => {
            if workload.is_contending() {
                false // High overhead in traditional distributed DBs
            } else {
                true
            }
        }
    }
}

So, if CockroachDB scales in all three dimensions, is it automatically the superior choice? Perhaps...