Sharding Plus Replication — Shards Spread Over Nodes Diagram

A shard is a partition in Kafka, a range in CockroachDB, a region in HBase and TiDB, a vBucket in Couchbase, a vnode in Riak, a token-range in Cassandra, and a tablet in Bigtable, YugabyteDB, and ScyllaDB
PostgreSQL separates partitioning (one machine) from sharding (many machines); elsewhere the words are synonyms
Sharding has nothing to do with network partitions (netsplits)

Sharding is the answer to too much data or too much write throughput for one node; read scaling can use replication instead
It is the main tool of horizontal scaling — grow by adding small machines, not by buying a bigger one
It is heavyweight: you must choose a partition key, the scheme is hard to change, and joins or writes across shards need distributed transactions
If one machine can handle the load, a single-shard database is usually the better choice

Per-tenant shards give resource and permission isolation, per-tenant backup and restore, and cell-based fault isolation
GDPR and CCPA export or delete becomes an operation on one shard; data-residence laws can pin a shard to a region
Schema migrations can roll out tenant by tenant
Hard parts: one tenant too big for a node, too many tiny tenants, and joins across tenants