A database can become the limiting component while the application tier still scales comfortably. At that point, splitting data across multiple databases can look inevitable. Sharding can distribute sustained writes and storage growth, but it also changes how the application locates records, joins data, commits transactions and recovers from failure. The decision begins with identifying the limit that one database can no longer absorb.
A larger instance, better queries, a read replica and a shard are responses to different bottlenecks. Putting each tenant or key range on its own database only pays when the workload can keep most important operations inside those boundaries. Otherwise, the architecture gains more databases while every request still needs to coordinate across them.
Keep one authoritative database until measured write throughput, storage growth or isolation requirements exceed a credible single-database path. Shard only when a stable key can place most routine work on one shard.
Find the limit before distributing data
“The database is slow” is not a sharding requirement. Start with the work that consumes capacity. Is latency rising because writes saturate storage or transaction logs? Are transactions waiting on a few contended rows? Is a large historical table making maintenance awkward? Are expensive reads competing with writes? Is one tenant responsible for most of the load?
These diagnoses lead to different changes. A hot counter remains hot if every update still targets one shard. Poor indexing follows the data into every new database. A growing read workload may be addressed by caching or replicas; the choice between a cache and a read replica is a separate question from distributing writes. Batch processing, retention rules and query changes may recover capacity without introducing a routing layer.
Measure the shape of demand, not merely the average utilization. Track write latency by operation, transaction wait time, log and storage pressure, the most active keys or tenants, growth by dataset, and the share of queries that touch multiple entities. A system that fails only during short ingestion bursts may need a controlled queue and backpressure. A system whose sustained useful write load grows beyond a single database’s practical headroom has a different problem.
Sharding distributes work that is already separable. It does not repair work concentrated on one record or a query pattern that needs the whole dataset.
Build the strongest simple baseline
A single primary database preserves a valuable property: transactions, constraints and operational visibility have one authoritative home. Before losing that simplicity, use the capacity and data-management options available within it. Right-size the instance, remove unnecessary writes, tune the expensive queries, and establish retention or archival for data that no longer belongs in the active working set.
Table partitioning inside one database can make large tables easier to manage and help some queries inspect less data. It is not the same as moving independently owned data onto separate database servers. The PostgreSQL partitioning documentation, for example, describes partition pruning and maintenance while also showing how constraints across partitions affect schema design. A partitioned table may solve a retention or query problem without solving a saturated instance’s write ceiling.
Separating read traffic can also protect the primary, provided that reads are the cause of pressure. If the writes themselves are saturated, another read copy does not create more write ownership. A managed database may reduce maintenance work, but its advertised scale still has to be checked against the workload’s actual transaction and storage profile. The managed service decision changes who operates the database; it does not remove the need to understand its limits.
| Architecture | What it can improve | What remains difficult |
|---|---|---|
| One tuned database | Simple transactions, one recovery path and better use of existing capacity | One primary write and storage ceiling |
| Partitions within one database | Data lifecycle and selected query patterns | Shared instance capacity and engine-specific constraint rules |
| Independent shards | Write and storage load across separate databases | Routing, cross-shard work, rebalancing and fleet-wide operations |
Choose a boundary that contains normal work
Sharding assigns each record to a database according to a shard key and a mapping rule. A tenant ID can work well when most requests, transactions and administrative actions belong to one tenant. A stable customer or account ID may serve a similar purpose. The key should distribute load, be available to the request path and rarely change. It also needs enough distinct values that growth does not pile onto a few shards.
Even distribution alone is insufficient. Hashing an identifier may spread records well while turning range queries into work across every shard. A time-based range can keep recent queries local but concentrate new writes in the newest range. A tenant key can preserve locality until one unusually large tenant overwhelms its assigned database. MongoDB’s shard-key guidance explicitly connects distribution with common query patterns and warns about uneven load and reduced query performance; the same design tension applies beyond that database engine.
Test the candidate key against the actual operations: creating an order, reading its items, updating a balance, enforcing uniqueness, producing a customer report and deleting a tenant. For each operation, ask whether the key is known before the query and whether all affected data can live together. If a normal transaction spans several tenants or requires a global join, the shard boundary cuts across the application’s natural unit of work.
A cross-shard query must locate several databases, execute work there and combine the results. The slowest or unavailable shard can influence the result and its latency. Global uniqueness and referential integrity become application or platform design questions rather than assumptions that one database will enforce automatically. The Azure Architecture Center sharding pattern discusses this coordination cost alongside key selection and data movement. These are consequences of distribution, not defects that a better router can erase.
Take the busiest real user journeys and route them on paper. If the request cannot identify its shard early, or a frequent transaction crosses shards, revisit the data boundary before building the routing layer.
Plan for movement and partial failure
Once data is sharded, a mapping becomes part of the production system. It may be a deterministic function, a lookup service or a directory of tenants and their locations. Every writer and reader must agree on it. A stale mapping can send writes to the wrong place or make a migrated tenant appear missing. The mapping therefore needs its own availability, versioning and recovery strategy.
Shards can fail independently, which can limit the affected tenants. The application must nevertheless define what partial availability means. Can unaffected tenants continue? Can a fleet-wide report return incomplete results? Can background jobs retry one shard without replaying work on all the others? Dashboards must show latency, errors, capacity and replication health per shard, as well as the aggregate. A healthy average can conceal one failing tenant group.
Operating a fleet changes routine work. Schema migrations must reach every shard without leaving incompatible versions active. Backups and restores need shard identity and consistent routing metadata. Security policy, secrets, access reviews and incident runbooks multiply. A managed sharding service may automate placement and movement, but the application still owns its query shape, consistency expectations and response to partial failure. This is another form of the broader state-placement decision: the state has to be discoverable and recoverable even as compute instances come and go.
Rebalancing is the long-term test of the design. If one shard grows too large, how will data move while reads and writes continue? A simple modulo rule over the physical shard count can remap a large share of keys when a new shard is added. Virtual partitions or a lookup map offer more controlled movement, at the cost of metadata and operational discipline. A hotspot caused by one heavily used tenant may require isolating that tenant rather than splitting every other tenant into smaller pieces.
Migration into sharding deserves a separate plan. Backfill historical records, route new writes to the intended owner, reconcile differences, and switch reads only when both data and mapping are trustworthy. Dual writing without a recovery protocol creates ambiguity when one write succeeds and the other fails. Define how to detect missing or duplicated records, how long the old source remains authoritative, and what a rollback can still restore. The point of no easy return arrives when new authoritative writes exist in more than one shard.
Count the cost of the new operating model
Sharding can defer the next single-instance ceiling and isolate workloads, but it rarely lowers the bill simply by adding databases. Each shard may require a minimum amount of compute, storage, replica capacity, backups and monitoring even when its load is low. Routing, cross-shard network traffic, rebalancing and test environments add cost. The number of operational objects grows with the fleet: more upgrades, alarms, credentials and recovery exercises.
The comparison is not “one large database versus several smaller ones” at one point in time. Model the expected growth curve, the cost of keeping headroom on the single database, and the utilization that separate shards can realistically achieve. Include the engineering time to build routing and to keep it correct. A large tenant whose workload needs dedicated capacity may justify one isolated database before the entire platform is sharded; that is a narrower commitment with a clearer payoff.
There is also a future cost of changing the key. The first key becomes embedded in APIs, queries, operational tools and possibly customer identifiers. If the workload’s access pattern changes, resharding may require a large data movement project. Choose a key from observed access and growth patterns, then document which assumptions would force reconsideration.
Every shard is another recovery unit. The architecture earns its place only when the capacity or isolation gained is worth operating that fleet.
Make the decision at the write boundary
Start with a single authoritative database and establish a capacity forecast from measured writes, data growth and latency. Correct avoidable work first. Use in-database partitioning when the real problem is data lifecycle or query pruning; use read scaling when the primary is carrying avoidable reads. Revisit sharding when sustained useful writes or storage growth approach a limit that vertical scaling and workload changes cannot meet at an acceptable cost or risk.
Before committing, prove four properties with representative traffic: a stable key routes most requests to one shard; the busiest keys can be isolated without rebuilding everything; cross-shard operations have explicit semantics; and a shard can be moved or restored without losing ownership of its data. Test a partial outage and a rebalancing operation, not merely an even distribution on a new empty dataset.
Sharding is justified when the database’s single-owner ceiling is real and the application’s data already has a useful boundary. If those conditions are absent, the more reliable scaling move is usually to keep the database coherent and remove the specific work that is exhausting it. Splitting data should follow a proven ownership model, not precede one.
Shard when a measured single-database limit and a stable, mostly local data boundary exist together. If either is missing, continue improving the simpler architecture.
Continue exploring data-intensive systems
Database ownership connects performance limits with infrastructure responsibility and long-term cost.
Cloud strategy, architecture and infrastructure decisions explained without vendor noise.