A workspace product's primary database is at its limits. Should it scale vertically, add replicas, or shard? What order and what evidence?

The ladder and its evidence

1. Vertical scaling. Underrated and frequently sufficient. Modern instances offer enormous CPU, memory and I/O, and doubling instance size is a maintenance window rather than a project. It buys time — often years — with essentially no architectural change. Evidence needed: almost none; just do it.

2. Query and index optimisation. Frequently buys an order of magnitude for the cost of a migration. Evidence: the top queries by total time. Teams skip this because it is unglamorous and it is usually the highest return per hour spent.

3. Read replicas. Scale reads nearly linearly, well-understood, reversible. Evidence: the bottleneck is genuinely reads. This must be verified — if the system is write-bound, replicas add cost and replication load while helping nothing, and they make the write bottleneck slightly worse.

4. Vertical partitioning. Moving a high-volume table family onto its own database. Far simpler than sharding a single table and often sufficient. Evidence: one table group dominates the load and has few joins to the rest.

5. Sharding. Evidence required: a single primary cannot absorb the write volume or hold the working set — write throughput near the sustained ceiling with no cheap wins left, working set materially exceeding memory, or a dataset whose routine operations (backup, restore, migration, index rebuild) no longer fit the maintenance window. And vertical scaling exhausted, meaning the largest available instance is already in use.

Why the order matters

Each step is progressively less reversible. Vertical scaling is a restart. Replicas can be removed. Sharding rewrites the data model, makes cross-shard queries application code, removes transactions across the data, and — crucially — makes the shard key an effectively permanent decision.

The workspace-specific note

When sharding does become necessary, the shard key should match the natural isolation boundary of the product — the workspace — rather than the most evenly distributed attribute. Every meaningful query is workspace-scoped, permissions are workspace-rooted, and per-tenant export, deletion and migration come free.

Uneven distribution across workspaces is then handled with a lookup routing table rather than hashing, so a single very large workspace can be relocated without touching anything else.

The mistake to avoid

Sharding for read volume, which is a category error — that is what replicas and caches are for — and adopting a distributed database to avoid sharding, which trades a known problem for an unfamiliar operational model and usually reintroduces the same partitioning decisions with less control.