SQL vs NoSQL

The Question Behind the Question

 "SQL or NoSQL?" is unanswerable as posed —
 it's really FIVE questions:

 1. What's the ACCESS PATTERN?     ad-hoc vs known queries
 2. What SCALE forces exist?       write rate, dataset size
 3. What CONSISTENCY do you need?  transactions vs eventual
 4. What's the DATA SHAPE?         relational vs nested/sparse/graph
 5. What does your TEAM operate?   skills are a real constraint

 answer those; the database picks itself.

The Scoring Table

Requirement	Points to	Points to
Ad-hoc queries, reporting	SQL ✓✓
Multi-entity transactions (money)	SQL ✓✓
Known simple lookups at huge scale		KV/wide-column ✓✓
Nested document reads		Document ✓
Massive write ingestion		Wide-column/TSDB ✓✓
Deep relationship traversal		Graph ✓✓
Text relevance ranking	Search engine (either way!)
Strict schema governance	SQL ✓
Schema churn speed		Document ✓

The Defaults That Serve Most Designs

 START: PostgreSQL. it covers:
 - relational + JSONB documents + full-text search + vectors(pgvector)
 - mature replication, tooling, hiring pool
 - vertical scaling to impressive heights before sharding

 LEAVE when MEASURED forces appear:
 - write throughput > single-node ceiling (~10-50k writes/s)
   → wide-column/KV for that workload
 - global multi-region writes with availability demands
   → distributed SQL or DynamoDB-style quorum stores
 - access pattern so fixed and hot that general-purpose
   overhead matters → purpose-built store

 "we chose Postgres" remains a STRONG interview answer
 in 2026 when justified by workload analysis.

The Transaction Litmus Test

 ask: "can two entities change together ATOMICALLY?"

 money transfer:      debit A + credit B      → NEED transactions
 like counter:        increment, loss OK      → don't need
 order+inventory:     reserve stock w/ order  → need (usually)

 needing transactions doesn't forbid NoSQL outright
 (Mongo has them now; sagas pattern exists) — but every
 workaround adds complexity budget you must defend.

Consistency Requirements Ladder

 STRICT (banking):    SQL single-writer / distributed-SQL
 READ-YOUR-WRITES:    quorum stores, or SQL + cache discipline
 EVENTUAL OK:         feeds, counts, analytics → anything
 
 most product data needs LESS consistency than engineers assume —
 EXCEPT money, inventory-at-purchase, and auth.
 classify each entity explicitly rather than whole-system.

Decision Walkthrough Example

 RideShare decomposition:

 trips/payments    → Postgres (transactions, reporting joins)
 driver locations  → Cassandra/wide-column (100k writes/s, keyed)
 session tokens    → Redis (TTL, hot reads)
 search            → Elasticsearch derived from Postgres
 analytics events  → Kafka → warehouse

 ONE product, FIVE stores, each justified by ITS workload.
 this is polyglot persistence — next lesson.

Interview Framing

Scored answers never say just “SQL” or just “NoSQL” — they DECOMPOSE: entity-by-entity requirements with a chosen store per class and one-line justification each. Including one deliberate “No, keep this in Postgres despite temptation” call (analytics via read replica) demonstrates restraint maturity that interviewers specifically probe for.