A national archives network is standing up a home for newly digitised object metadata coming from a dozen branches. Each branch's export carries a slightly different set of fields, the volume will grow into the tens of millions of records, and the conservation team wants to run PySpark notebooks directly against the data alongside ad-hoc SQL queries. Which Fabric data store best fits this requirement?
Select an answer to reveal the explanation.
Short Explanation
Think of a Lakehouse like an archive's open storage room: shelves can be rearranged as new box shapes show up, and researchers can walk in with either a spreadsheet or a full research kit. A Warehouse is more like a card catalog cabinet — precise and relational, but every drawer has to match the same layout.
Full Explanation
A Lakehouse stores data as Delta tables in OneLake and gives two ways in at once: a Spark engine for the notebook-based cleanup the conservation team wants, and a built-in SQL analytics endpoint for straightforward queries, all without moving the data. Delta's schema is evolvable, which matters when a dozen branches each export a slightly different field set — new or missing columns can be reconciled over time rather than rejected outright. A Warehouse is the wrong fit here not because it can't scale, but because it is built around a fixed relational schema and full T-SQL DML/DDL semantics that assume every load matches the same shape; that assumption breaks the moment branch exports diverge. An Eventhouse is optimized for high-velocity, time-series telemetry queried with KQL, not for slowly-changing structured object metadata that a data engineer wants to transform with Spark. Restricting a Warehouse to T-SQL-only access doesn't solve the schema problem either — it just removes the Spark option while leaving the rigid-schema issue in place. Before committing, check whether the branches' fields can be reconciled into a shared Delta schema over the first few ingestion cycles.