One database machine can only do so much — hold so many rows, and answer so many queries per second before it starts falling behind. This lesson covers three separate fixes for three separate problems: which TYPE of database to use in the first place, how to handle more READS than one machine can serve, and how to handle more DATA (or writes) than one machine can hold.
SQL vs NoSQL — a question about queries, not popularity
The choice between a relational (SQL) database and a NoSQL database should come from your ACCESS PATTERNS, not from which one sounds more "modern." Ask: does the data have real relationships that need joins across tables (favors SQL)? Do you need multi-row, multi-table ACID transactions — e.g. debit one account, credit another, atomically (strongly favors SQL)? Is the access pattern mostly "look this one thing up by its key," at extreme scale (favors a NoSQL key-value or wide-column store)? Does the schema itself change unpredictably and often (favors NoSQL's flexible schema)?
SQL and NoSQL options this course refers to
MySQL
PostgreSQL
MongoDB
Apache CassandraReplication: scaling reads
Leader-follower replication (also called primary-replica) has one leader node accept all writes, while one or more follower nodes continuously copy those writes and can serve read traffic. This directly fixes a read-heavy bottleneck: instead of every read hitting the single leader, reads spread across many followers. The cost is replication lag — followers are always slightly behind the leader, so a read from a follower can return data that's a few milliseconds (occasionally more) out of date.
Sharding: scaling storage and writes
Replication doesn't help once the DATA itself (or write volume) is too much for one machine to hold at all — every follower is still a full copy of everything. Sharding splits the data itself across multiple independent database instances, each holding only a SLICE of the total data.
Range-based sharding assigns each shard a contiguous range of keys (e.g. user ids 1–1M on shard 1, 1M–2M on shard 2) — this makes range queries efficient but risks hot spots if one range (often the newest, most active one) gets disproportionately more traffic. Hash-based sharding applies a hash function to the key to decide the shard, spreading load far more evenly regardless of key patterns, at the cost of making range queries across many keys expensive (they now have to hit every shard).
Consistent hashing
A naive hash-based scheme (hash(key) % number_of_shards) has a nasty property: adding or removing even one shard changes the result of that modulo for almost every key, forcing a massive reshuffle of nearly all your data. Consistent hashing solves this by mapping both shards and keys onto a conceptual ring — adding or removing one shard now only reassigns the keys that were specifically near that shard on the ring, not everything, which is exactly why it's the standard technique behind resharding in production systems.
Common mistakes
- Choosing NoSQL purely because it "scales better," without checking whether the actual access pattern needs joins or transactions.
- Confusing replication (fixes read load) with sharding (fixes total data/write volume) — they solve different problems.
- Range-sharding on a monotonically increasing key (like an auto-incrementing id or timestamp), which concentrates all new writes on the newest, single shard.
- Forgetting that sharding adds real complexity: cross-shard joins and transactions become much harder.
Quick recap
| Concept | One-liner |
|---|---|
| SQL vs NoSQL | Decide from access patterns: joins/transactions favor SQL; huge-scale key lookups favor NoSQL. |
| Replication | Copies of the same data, for scaling READS. |
| Sharding | Slices of DIFFERENT data, for scaling storage and writes. |
| Consistent hashing | Minimizes reshuffling when shards are added or removed. |
Practice Zone
Five MCQs, then two applied questions.
What is the strongest way to decide between SQL and NoSQL for a new system?
Asked in
In leader-follower (primary-replica) replication, what is 'replication lag'?
Asked in
A team shards users by ID range (1-1M → Shard A, 1M-2M → Shard B, ...). What problem does this create that hash-based sharding avoids?
Asked in
What is the simplest correct way to describe a database index?
Asked in
What specific problem does consistent hashing solve compared to plain hash(key) % N sharding?
Asked in
For a URL shortener, the dominant operation is 'given a short code, look up the long URL' — a simple key lookup, at huge read volume, with no complex relationships or multi-row transactions. Would you lean SQL or NoSQL, and why?
Asked in
A social app shards posts by hash(userId) % 8. One celebrity account (with 40 million followers) causes their shard to receive 100x the read traffic of every other shard. Sharding didn't fix this — why not, and what would actually help?
Asked in
FAQ
Can a system use both SQL and NoSQL together?
Yes, very commonly — a "polyglot persistence" approach uses SQL for transactional core data and a NoSQL store for a specific high-scale, simple-access-pattern feature (like a view counter) within the same overall system.
Does sharding always require NoSQL?
No — relational databases can be sharded too (many large SQL deployments are); sharding is a scaling technique independent of SQL vs NoSQL, though some NoSQL stores build sharding in natively.
Is replication lag always a problem?
Not for every feature — a few milliseconds to seconds of lag is invisible for most reads. It becomes a real problem specifically for read-your-own-writes scenarios, covered in the consistency lesson later in this course.