SQL vs NoSQL

• Map the four NoSQL families to their canonical workloads
• Explain when rigid schemas protect versus hurt
• Choose SQL vs NoSQL by query patterns and consistency needs

• SQL's strong integrity prevents corrupt data at the source; some systems must have it.
• NoSQL's flexible schemas absorb real-world shape shifts (event payloads, user-generated data).
• Scale story differs: NoSQL horizontal partitioning was designed for global scale; many SQL systems now scale well too.
• Knowing both lets you pick the storage that matches the access pattern instead of forcing one engine on everything.

A spreadsheet forces every row into the same columns and protects against typos — great for accounting. Index cards let each card say whatever it needs — flexible, but nothing stops a misspelled field finding its way in.

• SQL: schema in DDL; tables + relations normalized; joins at query time; ACID via row locks/WAL.
• Document stores (Mongo, DynamoDB-as-doc, Couch): one JSON document per record; embed related data; query by field, secondary indexes, aggregates.
• Key-value (Redis, DynamoDB pure KV, Memcache): get/set by key with blazing latency; no queries by arbitrary fields.
• Wide-column (Cassandra, HBase, Bigtable): sparse tables by (partition key, sort key); optimized for time-series and high write throughput.
• Graph (Neo4j, Neptune): nodes + edges; path and relationship queries ('who friends whom').

• Transactional source-of-record systems (ledgers, orders, users) typically live in Postgres/MySQL (SQL), and analytics reads from a warehouse.
• A session/token cache, leaderboard or queue uses Redis (key-value) for microsecond latency.
• Clickstream and IoT time-series land in Cassandra (wide-column) for massive write throughput.
• Fraud/relationship detection queries a graph store over connect-the-dots networks (Neo4j).

• Start relational unless you have a concrete reason (scale, flex-schema, latency) not to.
• Model NoSQL documents around the read path: embed what you read together, reference what changes independently.
• Design primary keys for your hot queries; NoSQL punishes scanning.
• Confirm the consistency semantics you need — NoSQL is often eventually consistent.

• Hash-parking everything into MongoDB and then writing cross-document joins the engine can't do.
• Choosing 'new tech' instead of the right fit and paying the schema-less tax (duplicated, drift-prone data).
• Ignoring that your NoSQL 'JSON column' still needs indexing for query speed.
• Storing denormalized data everywhere then discovering you need transactional updates across copies.

• Slow NoSQL query? Check the query pattern against the primary key/partition design first.
• Duplicate records across documents usually mean missing natural-key design or a race in client writes.
• If a 'schema-less' store keeps producing type errors, enforce the schema in the application/dto layer.
• Count 'full collection scans' — an index or a better key fixes the pain.