Vertical scaling (scale-up)
- What: Increase CPU/RAM/IO of a single managed instance.
- Cloud examples: AWS RDS/Aurora change instance class; Azure Database for PostgreSQL/GW scale compute tier; GCP Cloud SQL adjust machine type and storage.
- Operational complexity: Low (single instance change, possible reboot/short downtime), easy monitoring.
- Trade-offs: Limits of single-node capacity; schema changes easier (single copy). Resharding not applicable but migration to distributed architecture later can be hard.
Read replicas (scale-read)
- What: Asynchronous replicas for read-heavy workloads.
- Cloud examples: RDS/Aurora read replicas / Aurora Auto Scaling; Azure read replicas; Cloud SQL read replicas.
- Operational complexity: Moderate — replication lag management, failover planning, connection routing (proxy/load balancer).
- Trade-offs: Schema changes must be applied on primary and replicated; schema migrations that lock tables can cause replica lag. For resharding: replicas can help pre-warm data to new nodes.
Caching (Redis / ElastiCache / Memorystore)
- What: Offload hot reads, session/state cache, TTL-based coherence.
- Cloud examples: AWS ElastiCache (Redis/Memcached), Azure Cache for Redis, GCP Memorystore.
- Operational complexity: Low–moderate — cache invalidation, cache warming, client integration.
- Trade-offs: Requires cache invalidation strategy when schema changes alter query results; caching reduces need for sharding but doesn't solve write scale.
Partitioning & Sharding (scale-out)
- What: Horizontal data distribution by key/range.
- Cloud examples: Use Aurora Global DB with custom sharding; RDS + application-level sharding; Azure Cosmos DB partition keys; GCP Spanner/Cloud Bigtable auto-shard or Cloud SQL manual sharding.
- Operational complexity: High — routing layer, rebalancing, cross-shard transactions, operational tooling.
- Trade-offs: Schema changes and resharding are costly: changing primary key or partition key may require migrating data across shards (online migration tools, dual-write, versioned schema, background copy). Plan for immutable shard key when possible; use middleware (consistent hashing, shard map) and rolling migrations to minimize downtime.
Recommendations: start with vertical + caching, add read replicas, then evaluate sharding only when necessary. For migrations design backwards-compatible schema changes, use feature flags, dual-write/dual-read, and offline rebalancers to reduce impact during resharding.
