For the question every growing data platform eventually asks
Data Warehouse Consulting
Choosing storage before understanding the query pattern is how platforms end up rebuilding within a year. A warehouse rewards structure and shared definitions, a lake rewards flexibility and cheap scale, and this practice starts from what your actual queries look like, not from which term sounds more current.
Warehouse, lake or both, decided honestly
How query patterns, cost and team skills settle the warehouse-versus-lake question.
90 secSample frame · video pending01Before any schema is drawn
Warehouse against lake is a decision, not a trend.
Forcing every workload into a warehouse schema wastes engineering time on data nobody queries structurally, and dumping everything into a lake without governance creates a swamp nobody trusts. Four questions settle where a workload belongs.
Are your queries mostly structured and repeatable?
Recurring reports against known metrics fit a warehouse. Exploratory queries against unpredictable data fit a lake far better.
Does the data arrive with a stable shape?
Consistent schemas belong in a warehouse. Logs, events and files with shifting shape belong in flexible lake storage.
Who actually needs to run the queries?
Business analysts querying daily need warehouse performance. Data scientists exploring raw data can work directly against a lake.
What does the cost curve look like at your volume?
Warehouse compute costs more per byte queried. Lake storage costs less to hold but more to govern well.
| Warehouse | Lake | Lakehouse | |
|---|---|---|---|
| Data shape | Structured, modelled | Raw, any shape | Both, layered |
| Best query type | Recurring business reports | Exploratory, ML-ready | Either, by layer |
| Storage cost | Higher per byte | Lower per byte | Mixed by layer |
| Governance effort | Built into the model | Requires deliberate discipline | Needed at both layers |
| Team skill needed | SQL and modelling | Data engineering, cataloguing | Both skill sets |
02Agreed before any code
The ledger that keeps the build honest
Every storage engagement fixes the split before work starts: what you bring, what we build, what comes back, and what never leaves your control regardless of scope.
- Your side
You bring
- The structured sources reporting already depends on
- The metrics finance and operations currently argue about
- Any existing tables or spreadsheets acting as a stand-in warehouse
- Our side
We build
- A modelled warehouse schema built around the real metrics
- Transformation logic turning raw tables into governed marts
- Access controls matching who should see which data
- Your side
You receive
- One warehouse with one definition per core metric
- Query performance suited to daily reporting workloads
- A schema your analysts can extend confidently
Never leaves you
- Which metrics get modelled first
- Business definitions behind every metric in the warehouse
- Approval of every schema change before it ships
Where the line sitsModelling and building the warehouse is ours to run. Deciding what each metric should mean stays a call only your business can make.
03From query pattern to right-sized platform
Four stages, each closing on an artefact
Storage decisions go wrong quietly when nobody looked at how queries actually run before choosing a platform. This system closes every stage with something a stakeholder can inspect.
Study how data actually gets used
Real query logs and reporting needs are reviewed before any platform decision, so the choice reflects behaviour rather than assumption.
A query pattern written down honestlyChoose warehouse, lake or both
The recommendation names the fit plainly, including when a hybrid genuinely serves the workload better than a single choice.
A shape matched to the workloadBuild the chosen storage layer
Warehouse schemas are modelled around real metrics, or lake storage is catalogued for findability, matched to what was decided.
A modelled or catalogued platformHand over the operating model
Documentation, access controls and the cost model move to your team, so the next workload gets placed without calling us.
A platform your team can extend
04What actually drives the number
Four drivers, not a flat rate card
Storage work is priced against the assessment, not a template, because these four factors change the effort by multiples.
Volume and variety of the data involved
A handful of structured tables costs less to model than years of varied, unstructured historical files.
How many metrics need governed definitions
A warehouse with a handful of core metrics is simple. Dozens of overlapping metrics need a longer modelling phase.
Whether a hybrid lakehouse is genuinely needed
A single-platform build is more contained. A lakehouse spanning both layers takes longer to design correctly.
Existing platform debt to migrate away from
Greenfield builds move faster than migrating years of reports and pipelines off an outgrown platform.
05Evidence and proof
Platforms sized to how the data is actually queried.
Storage proof is a platform still fitting the workload years later, not a migration that merely completed. Every record here waits for written client approval before production.
Explore case studiesA logistics platform finally split reports from raw event data.
Tern kept dumping everything into one strained database. Splitting a governed warehouse from a cheaper event lake cut reporting query time and storage cost together.
- Report query time
- Cut sharply
- Raw storage cost
- Reduced materially
Sensor archives moved off an outgrown warehouse without a rewrite.
Nexa Foundry stored years of sensor readings inside a warehouse never sized for that volume. A lake absorbed the raw archive while reporting stayed on the warehouse.
- Warehouse compute load
- Reduced significantly
- Reporting downtime during the move
- None
Nobody had actually looked at how we query before recommending a platform to us. This time someone did, and it showed.
Sample · pending client approval
06Read this first
When a storage rebuild is the wrong spend
Selling a full platform rebuild to a team whose current warehouse still fits would cost more than it earns us in trust. The exits are marked before the pitch. When the build is justified, it runs on Snowflake, BigQuery or Redshift for warehousing, with cloud object storage underneath any lake layer.
Your current platform still fits your query pattern
A working warehouse or lake that matches how the business actually queries does not need replacing on principle.
- Data engineering
The real gap is pipelines, not storage shape
If data is not arriving reliably, fix ingestion first. The storage decision matters less until that is solved.
Your engineers should own this build directly
If your team understands the trade-offs and just needs capacity, extending it internally is the faster route.
| Shape | Best when | You direct | We carry |
|---|---|---|---|
| Scoped build | The right platform is already decided | Priorities and modelling scope | Storage delivery |
| Delivery pod | The platform will evolve with growth | Roadmap decisions each cycle | Engineering, modelling, releases |
| Team extension | Your leads already run delivery well | Architecture and standards | Named engineers and continuity |
07Straight answers
Asked before a storage platform is chosen.
01Is a data lake always cheaper than a warehouse?
Raw storage costs less per byte, but a lake without governance and cataloguing becomes expensive in a different way: time lost to unfindable or untrustworthy data. The honest comparison includes that hidden governance cost, not just the storage bill.
02Can we start with a warehouse and add a lake later?
Yes, and it is a common and sensible path. Structured reporting needs often show up first, with raw data volume arriving once the platform and the team have matured a little.
03What is a lakehouse, in practical terms?
A pattern combining warehouse-style governance with lake-style flexible storage, usually on one underlying platform. It suits organisations with both heavy structured reporting and growing raw or varied data, without maintaining two disconnected systems.
04How do you decide which platform fits our case?
By studying how queries actually run today: how structured the data is, who runs the queries, and how quickly it needs answering. The recommendation follows that evidence rather than a general preference for one architecture.
05Can you migrate us off a platform that no longer fits?
Yes, and the assessment states plainly whether a migration is actually warranted before any work is scoped. Many platforms labelled as outgrown just need better modelling on what already exists.
06What does a warehouse or lake build cost?
Scoped builds are priced against data volume, metric count and whether a hybrid lakehouse is genuinely needed. Migrations off an existing platform add a cost tied to how much history has to move safely.
07Will our analysts be able to query the new platform themselves?
That is the design goal. Documentation and access controls are handed over at completion, and the schema is modelled so a business analyst can write a query without engineering help.