A Microsoft Fabric data engineer may operate a dimensional warehouse and an Eventhouse side by side. Both are analytical systems, but their execution engines, common query shapes and troubleshooting evidence differ. DP-700’s performance objectives explicitly cover optimizing warehouses, Eventstreams/Eventhouses and query performance. Tuning one engine using folklore from another can obscure the actual bottleneck.
Start from query intent and response-time target
Consider two requests. Finance wants net revenue by customer segment across three years of order history. Operations wants the number of failed payment events in the last fifteen minutes, by terminal. The first belongs naturally in a curated relational star schema with warehouse T-SQL; the second is time-windowed event investigation where KQL and Eventhouse fit well. Both could theoretically be expressed in other engines, but latency, concurrency, freshness and governance should drive the choice.
For either workload, capture a baseline: query text, parameter values, time range, input row count, output count, execution duration, capacity/load signals and correctness checks. One observed slow run could reflect transient contention; compare multiple comparable runs before rewriting logic.
Warehouse performance begins with cardinality and statistics
A Fabric warehouse uses statistics to estimate how much data a query step will process. If the optimizer badly estimates a join’s cardinality, it may select an expensive plan. Review whether statistics reflect recent data changes, especially after large loads. Microsoft documents both warehouse statistics and warehouse performance practices.
Before changing statistics, look for obvious query mistakes: a join missing its key, filtering a timestamp through an expression that prevents efficient pruning, selecting far more columns than needed, or a GROUP BY at the wrong grain. A many-to-many join from duplicated dimension keys can multiply output rows. Tuning a bad plan without fixing the invalid data model may make an incorrect answer arrive faster.
Batch writes rather than trickling tiny DML changes
Warehouse storage behavior makes frequent tiny insert/update/delete operations less efficient than appropriately batched loads for many workloads. Very small transactions can produce fragmented files and maintenance overhead. Organize incoming records into a staging set and apply a controlled merge or batch write under the workload’s supported semantics. Balance batch size against latency requirements; a near-real-time requirement cannot always wait for a single giant nightly write.
Write operations and query tuning are connected. A warehouse receiving poorly batched updates may be slow even when the SQL predicate is reasonable. Capture write volume, batch size, concurrency and file layout patterns in the diagnosis. Automatic maintenance helps, but it does not excuse arbitrary write patterns.
Warehouse monitoring offers evidence beyond a stopwatch
Microsoft’s Fabric Warehouse monitoring overview identifies workspace monitoring, Capacity Metrics, the Warehouse Monitor, query insights and dynamic management views among available tools. Use relevant execution records to distinguish query compilation, data access, blocking/resource contention and repeated retries. Store a representative slow query and a known-good baseline in the runbook with enough context to reproduce them safely.
Be cautious with raw performance comparisons across days when the capacity configuration or data volume changed. Improvement should be expressed as work per query, not only absolute elapsed time, and must include the same business result.
KQL tuning depends heavily on time bounds and query shape
A KQL query scanning a week of telemetry to answer a five-minute question wastes work. Apply selective time predicates and source-specific filters early. Restrict projected columns to what the query needs, aggregate at the intended grain, and inspect broad joins or string parsing steps. Eventhouse query performance should be measured against ingestion volume, partition/time organization and concurrency.
Illustrative KQL:
PaymentEvents
| where event_time between (ago(15m) .. now())
| where result == "declined"
| summarize declines = count() by terminal_id, bin(event_time, 1m)
| order by declines desc
This finds minute-level failure counts. It does not by itself prove that a terminal is currently offline, because delayed event delivery can distort the latest window. Compare event time and ingestion time before turning the result into an operational alert. Also test a broad historical query separately; optimization for a fixed recent window may not solve the needs of a quarterly audit.
Query acceleration versus native Eventhouse ingestion
Where supported, Real-Time Intelligence provides ways to query OneLake data via shortcuts and query acceleration. This is a design decision between reference access and native ingestion, not a magic speed switch. If the source dataset changes frequently and requires low-latency KQL operations, examine whether the chosen access method can meet that target. If the use case is occasional exploration of large shared Delta files, a shortcut path may avoid unnecessary copying—but permission and freshness behavior still matter.
The OneLake shortcut guide covers data ownership; the Eventstream/Eventhouse article covers time-window processing. Query optimization must not ignore either.
Spark performance is a third diagnosis path
Fabric Spark executes distributed transformations and can be slowed by shuffle, skew, tiny files and unsuitable partitioning. Those symptoms differ from a warehouse optimizer statistics issue or a KQL time filter issue. If a shared business dataset is slow in both warehouse and Spark, suspect a data distribution or volume change first; if it is slow in only one engine, investigate that engine’s query plan and input path. The Delta and Spark optimization walkthrough provides the parallel diagnostic checklist.
A reproducible three-engine experiment
Use a small synthetic dataset that includes 30 days of order events. Materialize a warehouse sales fact, stream raw events into an Eventhouse and create a Spark/Delta aggregate. Run three questions: daily revenue, last-15-minute event failures and a historical customer join. Capture runtime and output counts. Then remove a time filter from the KQL query, intentionally introduce a duplicate warehouse dimension key and make the Spark join highly skewed. Each exercise should reveal a distinct symptom and root cause.
Restore the correct query and data, confirm that totals reconcile, and only then assess optimization. In DP-700, the engineer’s job is to understand the engine, state the performance hypothesis and prove a safe improvement; an untested list of “performance best practices” is not enough.