Decision being made
Choose the store that matches the work
Decide which Fabric data store is the closest fit for the workload and whether a second store has a distinct, evidence-backed role. Do not begin with a familiar product name or assume every data project needs the same architecture.
Short answer
Match each option to its primary workload
Evaluate Lakehouse for flexible data engineering across structured and unstructured data, Warehouse for governed relational analytics and SQL reporting, Eventhouse for high-volume real-time event analysis, and SQL database for transactional application workloads. Evaluate Cosmos DB in Fabric when globally distributed NoSQL application data is material. A combination can be valid when each store has one clear job.
Intended audience
Who this guide is for
- Business and data leaders comparing Fabric options.
- Data, analytics, architecture, and application teams defining requirements.
- Advisers preparing an evidence-based internal decision.
Relevant evidence
Describe the workload before selecting a store
- Classify the primary work as analytical, transactional, real time, or a defined combination.
- Identify whether the data is structured, semi-structured, unstructured, or event based.
- Confirm whether the working language is primarily SQL, Spark, or Kusto Query Language.
- State the required freshness, query complexity, schema enforcement, transaction behavior, and application latency.
- Name who owns data engineering, database operations, analytics, governance, capacity, access, and reliability.
- Determine whether existing data can be referenced through a OneLake shortcut or analyzed through mirroring instead of copied.
Recommended capability
Use the smallest clear workload boundary
| Option | Start here when | Primary language or pattern | Do not assume |
|---|---|---|---|
| Lakehouse | Data engineering spans files and Delta tables, varied formats, exploratory analysis, or external lake integration | Spark plus a read-only SQL analytics endpoint | That it replaces a transactional application database or every governed SQL warehouse |
| Warehouse | Structured relational analytics, schema enforcement, enterprise reporting, and complex SQL queries dominate | T-SQL and relational warehouse patterns | That it is the default for varied raw files, Spark-led engineering, or application transactions |
| Eventhouse | High-volume telemetry, logs, time-sensitive events, and low-latency analysis are central | Kusto Query Language and real-time analytics | That it is a general-purpose relational reporting store |
| SQL database | An application needs transactional reads and writes plus operational analytics | Managed relational database and T-SQL | That it is the default large-scale analytical lake or reporting warehouse |
| Cosmos DB in Fabric | A globally distributed application needs low-latency NoSQL access and flexible JSON schemas | Distributed NoSQL application data | That every semi-structured analytics workload needs an operational NoSQL database |
Microsoft identifies OneLake as the common storage foundation. Shared storage does not make these items interchangeable; the workload and operating boundary still matter.
Why not the other solutions?
Rule out options for observable reasons
Why not Lakehouse?
It is not the default for a primarily relational, governed SQL reporting workload or a transactional application database.
Why not Warehouse?
It is not the default for varied file formats, Spark-led data engineering, transactional application writes, or high-volume KQL event analysis.
Why not Eventhouse?
It is specialized for real-time event and telemetry analysis, not general relational reporting or application transactions.
Why not SQL database?
It is designed for transactional and operational application workloads, not as the default analytical lake or enterprise reporting store.
Why not Cosmos DB in Fabric?
Its distributed NoSQL application boundary adds little when the requirement is conventional relational analytics, Spark engineering, or event analysis.
When an alternative becomes appropriate
Change paths when the workload changes
- Move toward Lakehouse when varied file and table data, Spark processing, exploratory analysis, or external lake integration becomes material.
- Move toward Warehouse when structured relational analytics, schema enforcement, high-performance SQL, and enterprise reporting become dominant.
- Move toward Eventhouse when high-volume telemetry, logs, time-sensitive events, or Kusto Query Language becomes central.
- Move toward SQL database when the system must support transactional application reads and writes.
- Move toward Cosmos DB in Fabric when globally distributed, low-latency NoSQL application data and flexible JSON schemas are required.
- Use more than one only when each boundary has a named workload, owner, evidence requirement, and cost question.
Risks and guardrails
Do not let a storage choice hide the operating model
Confirm data ownership, access, governance, lineage, quality, retention, performance, reliability, and cost controls. Check whether shortcuts or mirroring avoid unnecessary copies. Capacity and user-access requirements depend on the current tenant, region, agreement, workspace, and workload. A prototype does not establish production suitability. The responsible customer, partner, or technical team decides how to execute the work.
Questions to discuss internally
Requirements to confirm
- Is the primary workload analytical, transactional, real time, or a defined combination?
- Which data formats, query languages, freshness, transaction, and schema requirements are non-negotiable?
- Does the data already exist in a location that Fabric can reference rather than copy?
- Who owns data quality, access, governance, performance, reliability, and cost?
- Which evidence would justify more than one store?
- What Fabric capacity and user-access requirements must be verified before a final decision?
Public Microsoft sources
Verify the current Fabric boundaries
- Store data in Microsoft FabricOfficial comparison of Lakehouse, Warehouse, Eventhouse, SQL database, Cosmos DB, shortcuts, and mirroring
- What is Microsoft Fabric?Official Fabric, OneLake, workload, governance, and platform overview
- Understand Microsoft Fabric licenses and capacityOfficial tenant, capacity, workspace, per-user access, and workload boundaries
Verification date
Check current requirements before deciding
Source review completed . Fabric items, capacity, user access, regions, features, and terms can change and may vary by tenant, cloud, subscription, workspace, agreement, and release status.
Exact next destination
Place Fabric in the wider Microsoft AI decision
Finished this primer?Optional progress stores only this primer identifier and a completion time on this device.