Which Dock Does Your Cargo Actually Need?

Opening Scene

After touring the whole port — the depot, the wharf, the integrated modern terminal running both — a shipper still has to answer one very practical question for every shipment: which dock does this cargo actually need? Not which dock is newest, or most impressive, or what a competitor uses. Which one actually fits this cargo, this volume, this urgency, this budget. Get the answer wrong, and even the best-run dock in the world is the wrong choice.

This article is a deliberate decision framework, pulling together everything the last eighteen articles have covered.

In Plain English

Choosing between a warehouse, a lake, and a lakehouse isn’t about which is objectively “best” — it’s about matching architecture to actual need. A warehouse still makes sense for stable, well-understood, heavily-queried structured data where upfront schema investment pays off. A lake still makes sense for cheap, flexible storage of data whose value or shape isn’t fully known yet. A lakehouse makes sense when an organization genuinely needs both patterns over overlapping or shared data, and can support the added architectural sophistication that requires.

The Old Way

Historically, this decision was often made once, early, and rarely revisited — an organization picked a warehouse or a lake as its core platform, and that choice quietly became the default answer for every new use case afterward, regardless of fit. This series has already described the costs of that pattern in Article 6: a single organization-wide default serving genuinely different use cases poorly.

Even when organizations recognized they needed both, the lack of mature lakehouse technology historically meant the “both” answer came with real integration costs (Article 4) — so the decision often got made based on which system was already in place and easiest to extend, rather than which pattern actually fit the new use case best.

What’s Changing (and Why AI Is the Reason)

Lakehouse maturity has genuinely changed the shape of this decision. With a mature lakehouse option now on the table, the choice is less often “warehouse or lake, pick one for everything” and more often “does this specific workload need lakehouse’s added sophistication, or would a simpler warehouse or lake alone actually suffice” — a more nuanced, workload-specific question than the older, blunter version of this decision.
AI workloads are shifting the calculus toward needing both patterns more often. As this series has repeatedly noted, AI workloads frequently want both structured, warehouse-style access and raw, lake-style access to overlapping data — pushing more organizations toward genuinely needing lakehouse capability, rather than being able to comfortably pick just one side.
AI-assisted architecture recommendations are emerging as a genuine input to this decision. Rather than relying purely on manual analysis, some platform tooling can now assess actual workload patterns and recommend an architecture fit — a meaningful decision-support aid, though still one requiring human judgment about business context that no tool can fully capture.

The Metaphor, Fully Extended

Harbor Element	Architecture Decision Concept
A shipper choosing a dock based on cargo type, not habit	Matching platform architecture to actual workload needs
Defaulting to whichever dock the company already uses, regardless of fit	Inheriting a platform default rather than deciding deliberately
A cargo type that genuinely needs both depot and wharf capability	A workload genuinely requiring both structured and raw access
A dockmaster consulted for a recommendation, still requiring the shipper’s final judgment	AI-assisted architecture recommendations, requiring human review

For Beginners: What to Actually Do

Practice articulating, for any dataset or use case you encounter, an explicit answer to “warehouse, lake, or lakehouse, and why” — treat it as a standing exercise, not a one-time decision to memorize.
Revisit the earlier articles in this series (particularly 2, 3, 4, and 6) as reference points when working through this decision for a real use case — this article is a synthesis, not a replacement for that underlying detail.
Resist the pull toward whichever architecture is most discussed or fashionable, and anchor instead on the concrete criteria this series has built up: data stability, query patterns, need for both structured and raw access, and team readiness for the sophistication involved.
When you don’t have enough information to decide confidently, say so explicitly rather than guessing — a well-reasoned “I need more information about the query patterns first” is a stronger answer than a confident guess.

For Practitioners and Leaders: The Deeper Layer

Make this decision-making framework explicit and documented at your organization, rather than leaving it as implicit tribal knowledge — that documentation pays for itself the first time a new team faces the same choice without institutional memory of how past decisions were made.
Revisit past architecture decisions periodically, not just new ones — a choice that made sense under old constraints may no longer fit as AI workload demands and lakehouse maturity continue to shift the calculus described in this article.
Treat AI-assisted architecture recommendations as a genuinely useful input, but keep the final call with people who understand your organization’s specific constraints, technical debt, and team capabilities — context no general-purpose recommendation tool fully has access to.
The cost of getting this decision wrong compounds over time, the same way schema and format decisions do elsewhere in this series — invest proportionate care in making it well, even under real pressure to move quickly.

Quick Recap

Choosing between a warehouse, lake, and lakehouse should be a deliberate, workload-specific decision, not an inherited organizational default.
Historically, this choice was often made once, early, and applied broadly regardless of fit, creating real costs described in Article 6.
Lakehouse maturity and growing AI workload demands are both reshaping this decision toward more organizations genuinely needing lakehouse capability.
AI-assisted architecture recommendations are a useful decision input, but still require human judgment grounded in organizational context.

Where This Fits in the Series

Article 18 covered migration. This article pulled the whole series’ architecture questions into one practical decision framework. Article 20 closes the series, walking the entire harbor once more as one connected system.