SQL vs NoSQL Differences

Problem Compare SQL and NoSQL: why is it difficult to scale a relational database horizontally, and when would you pick each?

Be ready to discuss

• What makes relational scaling hard: joins and multi-row transactions assume co-located data, so distributing them requires cross-shard joins, distributed transactions, and two-phase commit — coordination that adds latency and failure modes.
• Sharding mechanics: choosing a shard key, hot/uneven partitions, resharding a live system, and the loss of global secondary indexes and cluster-wide uniqueness constraints.
• Read scaling versus write scaling: read replicas are the easy half and buy a lot of headroom; the single primary write path is what eventually forces partitioning.
• What NoSQL trades away: strict consistency and relational structure in exchange for horizontal scale, flexible schemas, and high write throughput — often eventual consistency, per CAP favoring A/P over strict C.
• Picking SQL: strong consistency, complex relationships and joins, ad-hoc reporting, transactional integrity — financial ledgers, order systems, anything with invariants across rows.
• Picking NoSQL: known simple access patterns at scale — session stores, catalogs, feeds, event logs, time series — where the query shape is fixed and volume is the constraint.
• Nuance worth raising: modern NewSQL/distributed SQL (Spanner, CockroachDB, Vitess) attack exactly this gap, so "SQL cannot scale" is dated — it is expensive, not impossible.