In this chapter
We'll turn the last chapter's honest trade-off into a real, two-question framework — genuine cross-model need, and distance from a specialist's own performance ceiling — and apply it directly to GreenMart's own eight-system inventory, some consolidating, some staying deliberately separate.
The Problem in Real Life
Sarah has the honest trade-off from last chapter. What she actually needs now is a decision, not a list of considerations — which of GreenMart's eight systems are genuinely worth consolidating, and which ones this whole course argued for specifically because nothing else does that one job as well.
Mike wants the real answer, not "it depends" left unfinished.
I don't need a philosophy. I need to know which two systems actually merge.
Mike
A General Trade-off vs. A Real, Specific Decision
Two real, checkable questions
Genuine cross-model need, and how close a workload sits to a specialist's own real performance ceiling.
Some pairs genuinely consolidate
MongoDB catalog + search is a real, good candidate — moderate scale, genuine reason to query together.
Some systems stay specialized, correctly
Cassandra's sensor telemetry and the graph database's fraud detection are each already operating near their own real ceiling.
Not every unrelated pair should merge
Fleet tracking and product embeddings share no genuine query need — forcing them together adds coupling, not simplicity.
Multi-Model vs. Specialized
Multi-model vs. specialized database, as an actual decision, comes down to two honest questions for any given pair of systems: how much does GreenMart genuinely need cross-model queries between them, and how far from that specialist's real performance ceiling is GreenMart actually operating? Both questions have real, checkable answers — not just gut feel.
| Pair | Genuine Cross-Model Need? | Near a Specialist's Ceiling? | Verdict |
|---|---|---|---|
| MongoDB catalog + search engine | Yes — search a catalog you already store as documents | No — catalog size is moderate | Good consolidation candidate (e.g. MongoDB Atlas Search) |
| DynamoDB fleet tracking + vector database | No — no real reason to combine truck telemetry with product embeddings | N/A — unrelated data entirely | Stay separate — not even a real pairing |
| Cassandra sensor telemetry (alone) | N/A — evaluated alone, at its own extreme write volume | Yes — genuinely at the write-throughput scale Cassandra exists for | Stay specialized — this is exactly Act 5's own case for it |
| Graph fraud detection (alone) | N/A — evaluated alone, deep traversal-heavy workload | Yes — genuinely needs real graph-specific performance | Stay specialized — a general-purpose graph bolt-on likely underperforms here |
Not every system needs a partner to consolidate with — some of GreenMart's eight are already the right, specialized choice on their own, and this framework says so honestly rather than forcing a merge.
When multi-model makes sense, concretely: a genuine, recurring need to query across two models together, at a scale comfortably inside what a multi-model system's own (usually slightly weaker) implementation of each model can actually handle — MongoDB's catalog plus its own Atlas Search is a real, good example, since GreenMart's catalog size was never pushing a dedicated search engine's own outer limits anyway.
When specialization is better, just as concretely: a workload genuinely operating near a specialist's own performance ceiling (Cassandra's real write-throughput scale, a graph database's own deep-traversal performance), or two models with no genuine reason to be queried together in the first place. Forcing DynamoDB's fleet data and the vector database's product embeddings into one system wouldn't reduce GreenMart's real complexity — it would just create an odd, unnecessary coupling between two things that were never actually related.
Key Takeaway
Multi-model vs. specialized isn't a single, once-and-for-all answer for GreenMart — it's a real, per-pair decision, answered by two honest questions: does this pair genuinely need to be queried together, and is either side already pushing a specialist's own real ceiling? Some of GreenMart's eight systems should merge. Some are exactly right staying separate, and this framework says so without flinching.
Why This Matters
This closes the loop this Act's very first chapter opened with: the honest cost of eight systems doesn't mean the answer is one system, or even fewer systems everywhere — it means making this exact decision, pair by pair, on real evidence, which is precisely the discipline GreenMart needs from here on.
GreenMart now has a real, working framework, applied honestly to its own actual inventory. The checkpoint ahead asks Sarah — or you — to audit GreenMart's actual database sprawl from scratch, with every one of this Act's lessons made on purpose.