Analytics & reporting (SQL wins)
Who uses it: Team building a BI or analytics product
Complex multi-table JOINs across users/orders/products
Aggregate queries (SUM, GROUP BY) over historical data
Schema enforced for data quality
Window functions, CTEs, and SQL ecosystem tooling
ACID matters when reports must reconcile with transactions
Why this works: Analytics is SQL's home turf — the diagram's left side, with normalized tables and JOINs, is what makes ad-hoc cross-entity queries possible. NoSQL can fake some of this but pays for it in denormalization complexity.
Content / catalog (NoSQL fits)
Who uses it: Team building a CMS, product catalog, or activity feed
Each item is a self-contained document
Fields vary per item type — schema would be 30 nullable columns in SQL
Read-heavy access pattern: fetch one document at a time
Easy to add new fields without migrations
Sharding by item id scales horizontally
Why this works: Content/catalog access is hierarchical and read-heavy — the diagram's right side, where one fetch returns the whole document, fits because most queries are 'give me this item' rather than 'join across items'.
Real-time app (depends on the operation)
Who uses it: Team building chat, gaming, or social features
User profiles and friendships → SQL (relational, transactional)
Chat messages and feeds → NoSQL (high write throughput, hierarchical)
Presence and sessions → in-memory KV store (Redis)
No single database fits all access patterns
Per-feature storage choice
Why this works: Real-time apps usually need both — the diagram captures the binary choice, but production reality is that different features sit on different sides of the line, each chosen by its own access pattern.
Polyglot persistence
Who uses it: Mature team running both technologies in production
Postgres for OLTP and source of truth
MongoDB / DynamoDB for content and event logs
Redis for caching and session state
Elasticsearch for full-text search
Each store wins on its specific access pattern
Why this works: Polyglot persistence is what most mature systems become — the SQL-vs-NoSQL diagram becomes a starting frame, but the production architecture overlays both, picking the engine that fits each access pattern.
