Fabric data store selection: lakehouse vs warehouse vs SQL database vs eventhouse
Verdict: Lakehouse for big data with mixed PySpark and read-only SQL. Warehouse for star-schema T-SQL BI. SQL database in Fabric for high-concurrency OLTP with enforced foreign keys. Eventhouse for high-volume streaming, time-series and geospatial.
| Criterion | Lakehouse | Warehouse | SQL database in Fabric | Eventhouse |
|---|---|---|---|---|
| Primary workload | Big data with mixed PySpark and read-only SQL | Star-schema relational BI in T-SQL | High-concurrency OLTP with enforced foreign keys | High-volume streaming, time-series and geospatial |
| Persona | Data engineers and scientists (PySpark, Delta, notebooks) | Warehouse developers and architects (star schema, T-SQL) | Application developers | Real-time analysts (KQL) |
| Key trait | Open Delta tables via SQL analytics endpoint | T-SQL DML, no direct Spark attach | Same engine as Azure SQL Database: ACID, auto-tuning | Fast time-series and geospatial query functions |
Rules
- Choose a lakehouse for big data with mixed PySpark engineers and read-only T-SQL consumers via the SQL endpoint.
- Choose Eventhouse for billions of rows of streaming data needing fast time-series and geospatial analysis.
- Choose SQL database in Fabric for high-concurrency OLTP with enforced foreign keys and automatic tuning.
- The decision guide pairs lakehouse with engineers and scientists, and warehouse with warehouse developers and architects.
Traps
- A warehouse targets star-schema BI and lacks native time-series and geospatial functions.
- A lakehouse does not enforce foreign keys or provide OLTP-grade ACID isolation.
- Eventhouse is for streaming and time-series, not relational OLTP with referential integrity.