Exercise 3: The Honest Nuance About JSONB and MongoDB — Possible Solution
====================================================================

WHAT JSONB DOES NOT REPLACE
------------------------------
Per this chapter, "this doesn't mean Postgres replaces MongoDB — a
dedicated document database still has real advantages at massive
horizontal scale, and a genuinely schema-less domain still fits
MongoDB's own design center better." JSONB blurs the line between
relational and document storage within a single Postgres database,
but it doesn't erase the two real advantages a dedicated document
database like MongoDB still has: MongoDB is purpose-built for scaling
horizontally across many servers, and for domains where essentially
EVERYTHING is variable/schema-less, not just a few fields alongside
otherwise-structured data.

WHERE JSONB GENUINELY DOES HELP
------------------------------
Per this chapter, "for the extremely common real-world case of
'mostly relational data, with a few genuinely variable fields,' JSONB
lets one Postgres database serve both needs at once, without the
added complexity of keeping two separate database systems in sync."
JSONB's real value is specifically for the common middle case — an
application that's mostly relational but has some genuinely flexible
data — not for a wholly document-oriented application at MongoDB's
own intended scale.

THE REAL TRADE-OFF NAMED IN THE WARN-BOX
------------------------------
Per this chapter's own warn-box, "the database can't enforce data
integrity or type-checking inside a JSONB value the way it can for a
real column — no NOT NULL, no CHECK constraint, no foreign key
reference into or out of a nested JSONB field." This directly
undercuts the exact strength postgres1-1 credited Postgres with in
its own "when to choose each" table — "data-integrity-critical
applications." If a genuinely important piece of an application's
data model gets pushed into JSONB purely for schema-flexibility
convenience, that data loses the database-level integrity guarantees
(required fields, valid ranges, foreign key relationships) that real
relational columns would have enforced. Per the chapter's own closing
line, "JSONB is the right tool for genuinely variable, secondary
data — not a substitute for real columns on the data that matters
most."

WHY THIS WORKS AS AN ANSWER
------------------------------
It states specifically what JSONB does NOT replace (MongoDB's own
scale and fully-schema-less use case), and connects the warn-box's
own integrity-enforcement gap directly back to postgres1-1's own
"data-integrity-critical applications" claim, showing the honest
limit rather than treating JSONB as an unqualified win.