Microsoft Fabric cheat sheet
Capacities, OneLake shortcuts, lakehouse versus warehouse items, and the Fabric concepts that differ from Synapse.
Core concepts
Tenant → Capacity → Workspace → Item- Capacity is the billing and compute unit (F2 through F2048). Workspaces are assigned to a capacity, items live in workspaces.
OneLake- One logical data lake per tenant, backed by ADLS Gen2 and storing tables as Delta. Every item reads and writes the same lake.
Lakehouse item- Delta tables plus a Files area, with a read-only SQL analytics endpoint. Spark and notebooks write here.
Warehouse item- Full T-SQL with read-write DML and multi-table transactions. Choose it when the workload is SQL-authored, not Spark.
F-SKU capacity units, not DWUs- Fabric bills capacity-seconds across all workloads, so a runaway notebook can throttle Power BI on the same capacity.
Shortcuts
OneLake shortcut to ADLS Gen2- Mounts existing lake data with no copy. The sane migration path from an existing Azure lake into Fabric.
Shortcut to Amazon S3 or GCS- Cross-cloud reads without a pipeline. Latency and egress apply, so it suits reference data more than hot paths.
Internal shortcut between workspaces- Share a gold table across domains without duplicating it. Permissions follow the source item.
Shortcuts are read-through, not cached by default- Every query hits the underlying store. For repeatedly scanned data, materialize into OneLake instead.
Ingestion
Data pipelines (Copy activity)- The Azure Data Factory engine inside Fabric. Same connectors, same parameterization patterns.
Dataflow Gen2- Power Query at scale for low-code transformation. Convenient for analysts, hard to code-review — keep it off critical paths.
Eventstream → Eventhouse- Real-time ingestion into a KQL database. The Fabric answer to streaming analytics and log-shaped data.
COPY INTO in a Warehouse item- Bulk load from Parquet or CSV in OneLake or ADLS. Fastest path for large batch loads into T-SQL tables.
notebookutils.fs- Filesystem helpers in Fabric notebooks, replacing dbutils for Spark work against OneLake paths.
Compute and modeling
spark.conf: Native Execution Engine- Vectorized C++ engine for Spark in Fabric. Meaningful speedup on scan-heavy jobs with no code change.
V-Order write optimization- Fabric-specific Parquet layout tuned for Power BI reads. Costs write time and pays back on interactive queries.
Direct Lake semantic model- Power BI reads Delta files directly — no import refresh, no DirectQuery latency. The main reason teams adopt Fabric.
Fallback to DirectQuery- Direct Lake silently falls back when guardrails are exceeded, and performance drops. Monitor it; do not assume it.
Governance and CI/CD
Workspace roles (Admin, Member, Contributor, Viewer)- Coarse-grained. Combine with item-level permissions and OneLake data access roles for real least privilege.
OneLake data access roles- Folder-level security inside a lakehouse. Closest Fabric equivalent to Unity Catalog table grants.
Git integration on a workspace- Syncs items to Azure DevOps or GitHub. Notebooks and pipelines version well; semantic models less so.
Deployment pipelines (dev → test → prod)- Promotes items across workspaces with rules for rebinding connections. Fabric's built-in release process.
Purview integration- Catalog, lineage, and sensitivity labels across Fabric items. Labels propagate to Power BI exports.
Choosing between items
Lakehouse when Spark or Python authors the data- Engineering teams writing PySpark should land in a lakehouse. The SQL endpoint still serves BI read-only.
Warehouse when T-SQL authors the data- Teams migrating stored procedures from Synapse or SQL Server want a warehouse item for read-write DML.
Eventhouse for logs and telemetry- KQL beats T-SQL for high-volume time-series and free-text log queries.
Do not run both patterns on the same tables- Pick one writer per table. Mixed Spark and T-SQL writers on one Delta table is where teams create corruption incidents.
From DataLane — tutorials at/blog, practice SQL live in theplayground.