In this chapter
We'll weigh consolidation honestly on both sides — real cross-model querying and less operational sprawl, against real costs in transaction boundaries, consistency, performance, and vendor trade-offs — treating a multi-model system as a genuine trade, not a strictly better option.
The Problem in Real Life
Mike hears "one system instead of two" and wants to consolidate everything, immediately. Sarah pumps the brakes — she's used pgvector enough to know it isn't simply DynamoDB and a dedicated vector database, merged, with nothing lost.
It's genuinely good at both jobs. It isn't identical to running the best possible specialist at each one, separately.
It does both jobs well. "Well" isn't the same as "as well as the specialist would."
Sarah
What Consolidation Buys vs. What It Actually Costs
Cross-model querying is the real prize
One query spanning two data models, natively — something no set of separate specialized systems can offer at all.
Transactions get harder across models
Strongest within one model; genuinely harder to reason about the moment one operation touches two models at once.
Performance is rarely quite as strong
A multi-model system's vector search or graph traversal is usually good, not automatically equal to a dedicated specialist.
Vendor trade-offs, the same concern in a new place
Fewer systems means deeper dependence on fewer vendors — the same lock-in concern Act 10 already named for a BaaS.
Consolidation Trade-offs
One system vs. multiple specialized systems is the real trade this Act keeps circling, and it has genuine costs on both sides, not just the operational-complexity cost the earlier chapters named. Consolidating buys something real and specific: cross-model querying — asking a single question that spans two data models in one real query, something no combination of separate specialized systems can ever offer, because a query can't natively cross a network boundary between two different products the way it can move within one.
What it costs is just as real. Transaction boundaries and consistency guarantees inside a multi-model system are usually strongest for operations that stay within one of its models, and get genuinely harder to reason about the moment a single logical operation has to touch two different models at once — the same kind of boundary earlier Acts already taught to take seriously, now showing up inside one product instead of across several. Performance trade-offs are real too: a multi-model system's vector search, or its graph traversal, is rarely quite as fast or as feature-complete as a dedicated specialist purpose-built for exactly that one job and nothing else — pgvector is genuinely good, not automatically equal to a purpose-built vector database at very large scale.
Vendor trade-offs close the honest accounting: consolidating onto fewer systems also means depending more heavily on fewer vendors, each one's own multi-model feature set, release schedule, and pricing — the same vendor lock-in concern Act 10 already named for a BaaS, here applying just as directly to a multi-model database chosen to reduce that exact kind of sprawl.
Key Takeaway
Consolidating onto a multi-model system is a real trade, not a strictly better move: it buys genuine cross-model querying and less operational sprawl, and it costs some of the performance, transactional clarity, and vendor independence a set of dedicated specialists would each have provided on their own. Neither side of this trade is free.
Why This Matters
This is the honest counterweight to last chapter's genuine excitement — a real capability isn't the same as a costless one, and every remaining decision in this Act depends on weighing both sides of this trade specifically, not just remembering that consolidation is possible.
GreenMart now has a real, two-sided account of what consolidating actually trades — genuine cross-model querying and less sprawl, against real costs in performance, transactional clarity, and vendor independence. Turning this into an actual, specific decision — merge this pair, keep that one separate — is exactly where the final chapter goes.