The NoSQL Landscape
You'll learn to
- -Name the four main NoSQL data models
- -Know when NoSQL beats SQL and vice versa
SQL's rigidity is a feature, until it becomes a bottleneck. A rigid schema means every write has to fit the same shape, and a single table's guarantees get harder to maintain the moment you need to split that table across multiple machines (a problem the next module tackles directly). NoSQL databases relax exactly this rigidity in exchange for horizontal scalability.
SQL = structured, relational, ACID-strong transactions. NoSQL = flexible, horizontally scalable, varied consistency models.
SQL is like a perfectly organized filing cabinet with labelled folders, cross-references, and mandatory forms. NoSQL is like a giant bin - you can throw anything in instantly, find things by key quickly, but complex "find everything related to X" queries require custom work.
SQL (Relational Databases) organize data into tables with rigid schemas. Data integrity is enforced by FOREIGN KEY constraints, NOT NULL, and UNIQUE checks. They guarantee ACID properties: Atomicity (all-or-nothing), Consistency (rules are never violated), Isolation (concurrent transactions don't interfere), Durability (committed writes survive crashes).
SQL's JOIN operation is the superpower: intricate queries linking dozens of tables in one round trip. This is perfect for e-commerce (orders + users + products + inventory all joined), banking (accounts + transactions + balances), or any domain with complex relationships.
NoSQL Databases trade strict schemas and JOINs for horizontal scalability and flexible data models. There are 4 main types: Key-Value (Redis, DynamoDB), Document (MongoDB, Firestore), Wide-Column (Cassandra, HBase), and Graph (Neo4j, Neptune).
NoSQL scales horizontally almost effortlessly because data is already partitioned by key - no need to coordinate complex JOIN operations across nodes. Writing 1 million events/second to Cassandra is straightforward; doing the same to Postgres requires extreme engineering.
The myth is "NoSQL is always faster." The truth: NoSQL wins on write throughput and simple key-based reads. SQL wins on complex queries, ad-hoc reporting, and systems requiring strict consistency. Many mature systems use both: Postgres for core business data, Redis for caching, Cassandra for time-series events.
- -Use SQL for: financial transactions, user accounts, inventory - anywhere ACID matters.
- -Use NoSQL for: time-series data, user activity feeds, caches, unstructured content.
- -NoSQL is NOT automatically faster - it trades query expressiveness for write throughput.
- -Schema-on-write (SQL) vs Schema-on-read (NoSQL Document stores).
- -NoSQL eventual consistency is a feature, not a bug - for the right use case.
Quick Reference: The Four Models
- -Key-Value: a giant hash map (Redis, DynamoDB). Fastest possible lookups by key, no querying by value.
- -Document: JSON-like nested records (MongoDB, Firestore). Flexible schema, good for content that varies shape between records.
- -Wide-Column: rows with dynamic, sparse columns grouped into families (Cassandra, HBase). Built for massive write throughput.
- -Graph: nodes and edges as first-class citizens (Neo4j, Neptune). Built for traversal queries like "friends of friends" that would need many expensive joins in SQL.
"NoSQL scales better than SQL, so we should just use NoSQL for everything." Agree?
"Yes, NoSQL is the modern, scalable choice."
"Not really: scalability is a trade against the guarantees you give up, not a free upgrade. A wide-column store scales writes beautifully but won't give you multi-row ACID transactions across an order and its inventory update. If a feature genuinely needs that, forcing it into NoSQL just moves the correctness problem into application code, where it's harder to get right, not easier."