A museum network's finance team needs to run complex T-SQL joins and aggregations across ticketing revenue and membership billing data, and several analysts are only comfortable writing SQL, not Spark code. Which Fabric data store best matches this need?
Select an answer to reveal the explanation.
Short Explanation
When the whole team already thinks in SQL, don't make them learn a new engine just to add up revenue. A Warehouse gives full T-SQL support, including transactional writes, which fits a finance team's join-and-aggregate workload directly.
Full Explanation
A Warehouse in Fabric is built for relational, T-SQL-first workloads and supports full transactional semantics across multiple tables, which matters for finance-style joins and aggregations where analysts need standard SQL rather than a Spark-based interface. It gives SQL-only analysts a familiar surface without requiring notebook or PySpark skills. A Lakehouse accessed only through Spark notebooks does offer a SQL analytics endpoint for read queries, but restricting access to Spark notebooks specifically forces exactly the skill mismatch the scenario is trying to avoid, and a Lakehouse's SQL endpoint does not support the same multi-table transactional writes a Warehouse does. An Eventhouse is designed around KQL for time-series and log-style telemetry; forcing ticketing and billing joins through KQL abandons the team's existing SQL fluency for no benefit, since this data isn't telemetry. A OneLake shortcut is a reference to data stored elsewhere, not a data store in its own right, and pointing one at another team's Lakehouse doesn't provide a T-SQL-first, transactional query surface for finance reporting. Before finalizing the design, confirm whether any source system truly requires Spark-based transformation upstream of the Warehouse, since raw ingestion and complex cleansing can still happen in a Lakehouse before the modeled, query-ready data lands in the Warehouse.