Greenfield Lakehouse Build – Case Study
- Greenfield Lakehouse
- Retail Analytics
- Cloud Cost Optimisation
- Data Warehouse Build
Project Snapshot
Client
Retail and Consumer Goods Group
Location
Retail operations across 26 markets
Industry
Retail & Consumer Goods
Services
- Greenfield Lakehouse Build
- Demand Planning Modernisation
- FinOps & Cloud Cost Optimisation
1. Introduction
A retail and consumer goods group needed to build its first modern data warehouse from the ground up. The business operated across stores, e-commerce channels, markets, suppliers, promotions, and demand-planning workflows, but reporting still depended on ERP extracts and analyst-maintained spreadsheets.
The build succeeded technically. The lakehouse went live, adoption grew, and the weekly planning spreadsheet was retired. Then a new problem appeared: cloud spend rose sharply as more teams started using the platform. The platform was working, but the operating discipline around cost, ownership, and usage had not been built early enough.
2. Business Context
The client operated across approximately 1,400 stores, three e-commerce channels, and 26 markets. Demand planning was a critical business process, but it relied heavily on weekly ERP extracts and spreadsheets maintained by a small number of analysts.
This created two major risks. First, the business was planning from delayed signals, while customer demand, stock movement, promotions, and channel behaviour changed daily. Second, the planning process depended on fragile spreadsheet logic that was difficult to scale, govern, or share across markets.
The organisation needed a modern data foundation that could support faster planning, broader self-service analytics, and trusted definitions across finance, supply chain, and commercial teams.
58%
Spend Reduction
Weekly→Daily
Planning Cycle
1→40+
Self-Service Users
6 Weeks
Cost Remediation
3. The Challenge
Unlike a legacy migration, this was a greenfield build. There was no old warehouse to reverse-engineer, no stored procedures to untangle, and no years of platform debt to unwind. That made the project appear simpler.
But greenfield programmes carry a different risk. With no legacy baseline, there is no natural constraint on what gets built and no easy comparison for what the new platform should cost to run. This is how teams can overbuild, over-refresh, and over-consume cloud compute before anyone notices.
The project needed to solve two problems at once: build a strong lakehouse foundation and create the operating controls required to keep cloud usage deliberate, accountable, and sustainable.
4. The Strategic Reframe
DataTheta reframed the programme from “build a warehouse” to “build a decision-ready lakehouse with cost accountability.” The goal was not simply to centralise data. The goal was to help teams plan faster, trust shared definitions, and use the platform without creating uncontrolled cloud spend.
4.1) Greenfield Freedom
Because there was no legacy warehouse, the team had freedom to design the right architecture from the start. That made it possible to build with open formats, a medallion structure, and a semantic layer before dashboards scaled.
4.2) Greenfield Risk
The same freedom also created risk. Without early FinOps discipline, teams could build more marts than needed, refresh dashboards too often, and consume shared computers without ownership or visibility.
5. The DataTheta Solution
DataTheta designed and implemented a greenfield lakehouse built for scalable analytics, demand sensing, and business-friendly self-service.
5.1) Lakehouse Foundation
The platform was built on open table formats and organised using the medallion pattern: bronze for raw ingestion, silver for cleaned and conformed data, and gold for business-ready marts. This created a structured path from raw source data to trusted business consumption.
5.2) Continuous Data Feeds
Point-of-sale, e-commerce, ERP, supplier, promotions, and weather signals were brought into the platform continuously rather than through weekly extracts. This helped close the gap between planning cycles and actual market movement.
5.3) Semantic Layer
Before the first dashboard was built, DataTheta worked with finance, supply chain, and commercial teams to define shared business terms such as net revenue and available stock. This prevented each team from creating its own version of key metrics.
5.4) Demand Sensing
Demand planning was connected to real signals, including sell-through, weather, promotional lift, and channel inventory. Planning moved away from static weekly extracts toward fresher, more responsive data.
6. Implementation Approach
The build succeeded in getting the platform live, but the cloud cost challenge required a second, corrective phase.
6.1) Build
DataTheta created the lakehouse foundation, connected key source systems, and structured the data into trusted layers for analytics and planning.
6.2) Adopt
By month eight, the platform was live and adoption was rising. The Monday-morning planning spreadsheet was retired, and more users began answering questions directly from the platform.
6.3) Diagnose
Cloud spend rose 4.3x between month four and month nine. DataTheta traced the problem to missing cost ownership, excessive dashboard refresh schedules, and over-modelled gold-layer marts that were built but not adopted.
6.4) Optimise
A six-week cost remediation effort introduced attribution by query, user, and team. Compute was right-sized, auto-suspend was enabled, refresh schedules were aligned to real usage, and unused gold-layer marts were retired.
7. Business Impact
The platform did not become cheaper because people used it less. It became cheaper because the organisation started using it deliberately. Monthly cloud spend settled 58% below its peak while platform usage continued to grow.
The business also moved from weekly to daily planning using live signals. Instead of relying on one analyst-maintained spreadsheet, more than 40 users could now answer their own questions from governed data. The result was a stronger analytics foundation, better planning responsiveness, and a more sustainable cloud cost model.
The most important lesson was clear: FinOps should not be added after cloud usage grows. It should be designed into the platform before the first workload goes live.
8. Conclusion
This case shows that a greenfield data platform can succeed technically and still create risk if cost accountability is missing. DataTheta helped the client build a modern lakehouse, retire fragile spreadsheet-led planning, and then correct the cloud operating model before damaging the business case. The final outcome was a governed, scalable, cost-aware platform used by more people, more often, at a lower run-rate.
How DataTheta helped a retail and consumer goods group build a greenfield lakehouse, retire spreadsheet-led planning, and bring cloud spend under control through FinOps discipline.
Related Case Studies
Greenfield Lakehouse Build – Case Study
14-day advance failure prediction
- Greenfield Lakehouse
- Retail Analytics
- Cloud Cost Optimisation
Cloud Data Warehouse Migration – Case Study
14-day advance failure prediction
- Warehouse Migration
- Teradata Modernisation
- Cloud Data Platform
Trusted Credit Data Foundation for Faster Lending Decisions
14-day advance failure prediction
- Banking & Financial Services
- Data Foundation
- Credit Risk Analytics
