Choose storage around the work you need to do.

Warehouses, data lakes, and lakehouse patterns organize data differently. Workload, governance, team skills, and operational overhead all belong in the decision.

Compare the patterns

There is no universal winner.

Use the table to frame a discussion. Actual capabilities vary by implementation and platform, so confirm the details for your environment.

Pattern	Often useful when	Questions to ask	Trade-offs to consider
Data warehouse	Structured analytics and governed SQL access are central	How do compute, storage, and access scale?	How will less-structured and ML workloads fit?
Data lake	Teams need flexible storage for varied file formats and processing	How will quality, cataloging, and access be managed?	Will users find consistent, trusted datasets?
Lakehouse pattern	Teams want shared storage foundations for multiple workloads	Which table formats, engines, and governance controls are supported?	How much platform and interoperability complexity is acceptable?

Operational questions

Think about use, cost, and control together.

Which queries or jobs run most often?
How much data must be retained, and for how long?
Who can create, read, share, and delete data?
Can teams reproduce a result from a known snapshot?
What happens to cost when usage spikes?

01 · Performance

Access pattern

Workload shape affects partitioning, clustering, caching, and compute choices.

02 · Governance

Data boundary

Classification and role-based access should follow the data through its lifecycle.

03 · Cost

Usage visibility

Measure storage and compute separately so owners can identify the drivers.

04 · Portability

Formats & interfaces

Document where data can move and which tools depend on platform features.

Decision ruleWrite down the main workload, users, governance boundary, and operating owner first. Then compare candidate storage patterns against those requirements.

Read architecture notes →