Microsoft DP-700: Lakehouse vs. Warehouse Design in Fabric

The lakehouse-versus-warehouse decision in Microsoft Fabric is not a contest between an old architecture and a new one. Both are first-class analytical patterns, both can participate in a Fabric solution, and both can support governed enterprise reporting. The DP-700 skill is knowing which model best fits the data, transformations, query patterns, and users in a given scenario.

Fabric also makes the boundary more flexible because OneLake provides a shared data foundation and the platform can expose data across engines without the traditional amount of copying. That flexibility is useful, but it can tempt teams to postpone architecture decisions. Good design still requires intentional choices about table shape, semantic ownership, write patterns, security, and performance.

Choose the lakehouse when engineering flexibility leads

A lakehouse is well suited to mixed file ingestion, Delta tables, Spark-based transformation, notebooks, and engineering workflows that need direct access to open data structures. It is especially useful when the same curated data should support code-centric processing and SQL consumption.

The strength is flexibility, but that does not mean “schema does not matter.” Table design, partition strategy, naming, quality rules, and curated layers still determine whether downstream consumers can rely on the data.

Choose the warehouse when relational serving leads

A Fabric warehouse is a strong fit for structured analytical serving, T-SQL-centric development, dimensional models, governed relational schemas, and teams that expect conventional warehouse behavior. It often provides a clearer contract for BI consumers who think in facts, dimensions, measures, and repeatable SQL access.

Warehouse design should still begin with business grain and query needs. Moving a poorly modeled relational schema into a managed warehouse does not make it analytically useful.

Use medallion layers to make transformation intent visible

Bronze, silver, and gold layers can help organize raw, validated, and curated data. The exact naming is less important than the separation of concerns. Raw ingestion should preserve source evidence, validation should improve quality and consistency, and curated layers should expose structures designed for consumers.

The pattern also improves recovery because teams can reprocess later stages without re-ingesting the source every time. That separation is valuable whether the curated output is served from a lakehouse, warehouse, or both.

Model grain before choosing indexes or partitions

Data modeling starts with what one row represents. In a fact table, unclear grain leads to double counting and broken measures. In a lakehouse table, mixed grain makes transformations and queries difficult to reason about. Architecture should settle the semantic unit before tuning physical layout.

The general warehouse-versus-lake comparison is useful background, but DP-700 scenarios require the next step: connect the model choice to Fabric workload and operational behavior.

Shortcuts can reduce copies without removing ownership

OneLake shortcuts allow a solution to reference data that remains in another location. That can reduce duplication and simplify access, but the architecture still needs an owner for the source, a contract for schema changes, security alignment, and performance expectations.

A shortcut is therefore a data-access design, not a governance shortcut. If the source changes unexpectedly, downstream consumers still experience the consequences.

Decide where transformations belong

PySpark notebooks can be ideal for complex engineering transformations, while SQL is often natural for relational shaping and serving. Dataflow Gen2 can be effective for low-code transformation, and pipelines can orchestrate the stages. The right design assigns work to the engine that best matches complexity, scale, maintainability, and team skills.

data engineering goes beyond writing transformations; engineers must maintain dependable data paths, operational controls, traceability, and recoverable deployments.

Design the serving layer for the consumer

Analysts, BI developers, data scientists, and applications do not need the same interface. A star schema in a warehouse may be ideal for governed reporting, while a lakehouse table may be better for engineering reuse or exploratory workloads. Serving design should reduce the amount of hidden transformation consumers must perform themselves.

Adjacent credentials such as Microsoft DP-600 focus more heavily on analytics engineering and semantic consumption, which helps clarify the DP-700 boundary: the data engineer should provide reliable, performant structures that downstream analytical layers can use.

Test architecture with change, failure, and growth

A design should be evaluated against more than the initial data volume. What happens when a source schema changes, a pipeline partially fails, data doubles, a region is added, or a new consumer needs different latency? These scenarios reveal whether the chosen table and serving architecture is resilient.

The exact Microsoft DP-700 target is useful because exam scenarios often combine architecture with monitoring and optimization. The best design is one that can be operated and evolved, not simply one that works in a demo.

Fabric makes lakehouse and warehouse patterns easier to combine, but good architecture still requires clear contracts. Know the grain, transformation stages, serving audience, security boundary, and ownership of every important data set.

For DP-700 questions, avoid deciding from product preference. Identify the workload and consumer first, then choose the structure that makes ingestion, transformation, governance, performance, and downstream use simplest to operate.

Schema evolution behaves differently across the two patterns. In a lakehouse, engineering teams may tolerate changing fields earlier in the pipeline and normalize them during curation. A warehouse serving many reports usually benefits from a more controlled contract. The architecture should place flexibility upstream and stability downstream when consumers need reliable schemas.

Partitioning decisions should follow access patterns. Partitioning by a high-cardinality field can create many small files, while ignoring a strong time-based access pattern can increase scanning. The design should consider how data is loaded, retained, compacted, and queried rather than copying a partition scheme from another workload.

Slowly changing dimensions are another warehouse-oriented design concern. If reporting needs historical versions of customer, product, or organizational attributes, the dimensional model should preserve that history intentionally. Engineering convenience should not erase the business timeline needed for analysis.

Lakehouse tables also need lifecycle management. Raw zones can grow indefinitely if retention is never defined, and intermediate tables can become permanent by accident. Storage policies should explain which layers preserve source history, which can be rebuilt, and which are authoritative for downstream consumers.

Data quality controls should be placed at the boundary where they are most useful. Early validation catches malformed source data before it spreads, while curated-layer tests confirm business rules and referential integrity. A single final check is usually too late to explain where the defect entered the pipeline.

When the same data feeds both engineering and BI workloads, avoid maintaining two independent copies unless a clear requirement justifies it. Fabric’s shared storage model and shortcuts can reduce duplication, but the architecture should still define which representation is authoritative and who owns changes.

Performance testing should use realistic query patterns and data volumes. A model that looks fast with a small sample may behave very differently after months of history or concurrent BI access. Measure representative loads, transformation windows, and query latency before declaring the design complete.

The lakehouse-versus-warehouse decision should also be revisited as the workload matures. A project may begin with exploratory lakehouse processing and later introduce a warehouse serving layer for governed reporting. That evolution is healthy when the boundary is intentional and the ownership model remains clear.

The two patterns also differ in how teams tend to collaborate. Data engineers may prefer lakehouse workflows that expose files and notebooks directly, while BI-focused teams often prefer relational contracts. Architecture should minimize friction between those groups by defining a curated handoff instead of forcing every user into the same tooling.

Security can influence the choice as well. Sensitive data may need separate workspaces, schemas, or curated outputs with different permissions. The physical pattern should make least-privilege access understandable rather than relying on complex exceptions layered over an ambiguous data model.

Operational ownership should be explicit for every major table or model. Someone needs to own source changes, quality rules, retention, performance, and downstream communication. Shared storage does not mean shared accountability.

Finally, document why the architecture uses a lakehouse, warehouse, or combination. Future teams should be able to see the workload assumptions behind the choice. When those assumptions change, the design can be revisited intentionally rather than preserved simply because “that is how the first version was built.”

Data observability should follow the architecture. Row counts, freshness, schema drift, failed transformations, and query latency can reveal whether the lakehouse or warehouse is still meeting its contract. Monitoring belongs with the model, not as a separate afterthought.

When both patterns are used together, keep the boundary simple enough that operators can explain where data becomes authoritative. Too many handoffs can recreate the duplication and ambiguity that Fabric is meant to reduce.

That clarity is what makes the design durable. A new engineer should be able to identify where raw data lands, where quality is enforced, where business-ready structures live, and which serving layer downstream users should trust.

For exam preparation, compare designs through trade-offs rather than slogans. Lakehouse is not automatically more modern, and warehouse is not automatically more governed. The correct choice follows the workload, transformation style, consumer contract, and operational model described in the scenario.