▶ YouTube Summaries

• YT :: https://www.youtube.com/watch?v=TPl45z8jdwg
• Original title :: The NoSQL Lie That Keeps Developers Overbuilding

NoSQL stores (DynamoDB, MongoDB, Redis, Cassandra-style systems) are legitimate tools for measured workloads, but most teams adopt them to move fast and avoid schema, or to pre-optimize for hypothetical scale they don't have - not because a measured workload demands it. The recommended default for product teams is relational (PostgreSQL, MySQL, SQLite, MariaDB), adding specialized stores only for specific, named needs.

Schema doesn't disappear, it relocates

A relational database forces early, explicit answers to questions like what's a customer, what's unique, what can't be null, what changes together. NoSQL lets you postpone those questions - store the document, add fields later, push validation into application code - but the schema still exists; it just moves into application conventions, code paths, and tribal memory, scattered across services instead of reviewed and migrated in one place. That's fine when records genuinely vary and blast radius is small; it's painful when product, finance, support, security, and on-call all need the same understanding of the same data.

Relational systems as an operational-truth service

Joins, constraints, and ad hoc SQL let a support engineer inspect customer state, an on-call engineer join across entities mid-incident, finance reconcile subscriptions, and product ask cross-entity questions that weren't anticipated six months ago. NoSQL can still answer those questions, but usually by adding machinery on top: streams, ETL, search indexes, warehouses, materialized views, duplicated read models, custom repair jobs - sometimes necessary, but if adopted just to avoid modeling the data, you may spend the next year rebuilding the query flexibility you gave up.

Where each specialized store actually fits

• DynamoDB: works well when access patterns are stable and business-critical, since its own design guidance is to model tables and keys around known reads/writes first - risky when the domain is still being discovered and changing every sprint.
• MongoDB: fits document/aggregate-shaped data that's usually fetched as a whole block, but real applications often still need atomicity across documents/collections, which pulls you back into transactions/consistency territory.
• Redis: valuable for caches, queues, counters, locks, rate limits, leaderboards, sessions, feature flags - ephemeral coordination, not a system of record.
• Cassandra-style / distributed systems: trade off consistency and availability explicitly (e.g. DynamoDB's eventually- vs strongly-consistent reads); fine when stale reads are acceptable, risky for billing, permissions, entitlements, audit trails, or cross-entity workflows. Google Spanner's existence - complex infrastructure and clock sync to get distribution and relational-style correctness together - shows how hard achieving both actually is.

The market signal

Relational engines (Oracle, MySQL, MariaDB, SQL Server, PostgreSQL, SQLite) remain the most widely used database technologies per Stack Overflow's 2024 developer survey, with MongoDB and Redis also high on the list - the real-world pattern is mixed persistence, not "NoSQL won" or "SQL lost." PostgreSQL's own JSON/JSONB support often means teams reach for a document database when their relational system already offers the flexibility they need.

The practical rule

Default to relational for the system of record (customers, accounts, permissions, subscriptions, invoices, audit trails, reporting). Add specialized stores derived from that source of truth for specific needs (cache/coordination, search, warehouse, object storage, access-pattern-driven workloads) rather than as a replacement for it. Before adopting a NoSQL store as the source of truth, the team should be able to answer: exact reads/writes, what must be strongly consistent vs can be stale, failure modes, how support inspects state, how analytics queries it, how migrations and data repair work. If the team can't answer those, they're using a database choice to avoid domain clarity - and unexamined schema, not schema itself, is what actually costs you later.