# A Decision Framework: SQL or NoSQL — System Design

Source: https://www.geekswithgeeks.com/en/system-design/sd-sql-nosql-framework

> Going beyond hype to pick the right store per workload.

## Ask about the shape, not the label

Instead of 'SQL or NoSQL', ask: How related is the data (many joins vs self-contained documents)? Do transactions need to span multiple entities? Is the schema stable or evolving fast? Will scale exceed a single node's write capacity?

## A quick matchup

Payments, inventory, anything needing multi-row ACID → **relational**. A user's session/profile blob accessed by key → **key-value**. A social graph of connections → **graph DB**. Time-series metrics at huge write volume → **wide-column** (Cassandra) or specialized time-series stores.

## Polyglot persistence is normal

Large systems mix stores: Postgres for orders, Redis for sessions, Elasticsearch for search, S3 for blobs. Pick per access pattern rather than forcing one database to do everything.