Data Lake, Warehouse or Mart? The Architecture Behind a Supply Chain AI Platform

Every few weeks, a client asks some version of the same question. "We already have a data warehouse — why do we need a data lake too?" Or the reverse: "We built a lake last year, isn't that enough?" The honest answer is that a lake, a warehouse and a mart aren't three ways to do the same job. They're three different jobs that happen to sit on one pipeline — and confusing them is the most common reason supply chain data projects stall at the "we have the data but nobody trusts it" stage.

This issue is the mental model we give clients before any tooling conversation happens. No vendor names, because the layers matter more than which product implements them.

What Each Layer Actually Answers

Before the diagram, the table. Every layer below answers a question the others cannot:

Bronze, Silver, Gold — in One Sales Row

The refinement stages aren't abstract. Take one row of sales data arriving from a store's POS system:

Why the Warehouse Doesn't Retire Once You Have a Lake

This is the part that trips teams up. If Gold is already clean and business-ready, why load it into a warehouse at all? Two reasons: query speed — a dimensional model with proper fact and dimension tables answers "OTIF by supplier by month for the last three years" in seconds, where scanning lake files directly does not — and access scoping. Procurement shouldn't need warehouse-wide access just to see supplier lead times.

Marts don't duplicate the warehouse's logic — they filter it. That's the whole design: one governed set of facts and dimensions, scoped three different ways.

Where Forecasting, Optimisation and AI Agents Plug In

This is also where our own DAPP → RESO method lives in the architecture, not just in a slide. The Data and Algorithm steps run on the feature store — lag values, rolling means, promotion flags, engineered from Gold, versioned so you always know which feature set trained which model. The Predict + Prescribe steps hand a forecast to an optimisation solver — order quantity, reorder point, route — constrained by real lead times and MOQs, not a spreadsheet guess.

An agent that only reads raw lake files inherits every inconsistency in your source data and has no fast way to answer a three-year trend question. See Issue #15 — Agentic AI for Supply Chain Planning for the guardrails and build steps once these layers exist; the agent is only as good as whether they do.

A Pragmatic Build Order

We rarely recommend building all of this at once, even for clients who can afford to. Six stages, roughly in sequence:

1. 01
   FoundationSQL database, Power BI, Excel. Source → database → dashboard. Gets a real number in front of decision-makers in weeks, not quarters.
2. 02
   Data engineeringData lake, Bronze/Silver/Gold, orchestration, and the data-quality checks that catch a negative quantity before it reaches a dashboard.
3. 03
   Enterprise analyticsWarehouse, data marts, and one semantic layer — so "OTIF" is calculated once and means the same thing in every report.
4. 04
   Machine learningFeature store and demand forecasting, from a moving-average baseline up through XGBoost or a temporal fusion transformer where SKU count justifies it.
5. 05
   OptimisationTurn the forecast into a decision — order quantity, safety stock, route — subject to the constraints that actually bind: capacity, MOQ, service level.
6. 06
   AI agentsTool-calling agents that query the warehouse, call the forecast, and read the contracts — in one conversation, once stages 1–5 give them something real to call.

The Honest Summary

A data lake, a warehouse and a mart are not a menu you pick one item from. They are stages a business passes through as more people need to trust the same numbers, and as more of the "what should we do" question gets handed to a model instead of a spreadsheet. Build the stage the current quarter's problem actually needs — not the stage a vendor's architecture diagram says you should be at.