I’m currently building an AI-ready data lake on Microsoft Fabric. Fabric makes it very easy to get started, and that’s part of the risk: a few early decisions are hard to undo once dozens of pipelines and reports depend on them. These are the tips I now give every team on their first week.
1. Reach for OneLake shortcuts before you copy anything
If the data already lives in ADLS Gen2, Amazon S3, an S3-compatible store, Google Cloud Storage, Dataverse or another Fabric item, a shortcut lets you use it in place, with no extra copy and no extra pipeline to babysit. Remember that shortcuts in the Tables folder can only be created at the top level, and that external shortcuts authorise through a cloud connection, so treat those connections as governed assets. For cross-cloud sources, workspace-level shortcut caching can cut egress costs.
2. Decide V-Order per layer, not globally
V-Order is a write-time Parquet optimisation that speeds up reads across Fabric engines, at the cost of slower writes. In new workspaces it’s off by default (spark.sql.parquet.vorder.default is false), which suits bronze and silver ingestion. For gold tables that Power BI and the SQL analytics endpoint read all day, I switch it on at table level with the delta.parquet.vorder.enabled table property, or use one of the read-heavy resource profiles.
3. Keep your Delta tables tidy
Lots of small files hurt every engine, and Direct Lake especially. Schedule OPTIMIZE to compact files and VACUUM to clean up old ones, either from a notebook or from the lakehouse table maintenance option. Make it part of the pipeline, not a job someone remembers to run once a quarter.
4. Design workspaces around lifecycle and ownership
I keep separate development, test and production workspaces, connect development to Git, and promote with deployment pipelines. Workspaces are then grouped into domains so that ownership is visible. A workspace that mixes everyone’s experiments with production reports is hard to secure and harder to clean up.
5. Plan capacity like a shared resource, because it is
All workloads in a capacity draw on the same capacity units. Bursting and smoothing absorb short spikes, but a heavy Spark backfill can still slow down the reports sharing that capacity. Where budget allows, I put production reporting on a different capacity from development and heavy engineering, and I watch usage in the Microsoft Fabric Capacity Metrics app from day one.
6. Choose your Direct Lake flavour on purpose
Direct Lake on OneLake reads Delta tables directly and never falls back to DirectQuery. Direct Lake on SQL analytics endpoints can fall back to DirectQuery, for example when a table is really a SQL view or the warehouse uses SQL granular security, and the semantic model’s Direct Lake behaviour property controls that fallback. Either way, build gold as physical Delta tables, not views, and check the capacity guardrails for your SKU.
7. Make gold AI-ready, not just report-ready
If a Fabric data agent or Copilot is going to query your data, names and descriptions matter. Use clear business column names, add descriptions, and keep one well-defined table per business concept. When I set up a data agent, the agent instructions and example queries do more for answer quality than any amount of prompt tweaking.
Wrapping up
None of this is complicated, but it all gets harder to change later. Get shortcuts, table maintenance, workspace layout and capacity right early, and Fabric stays pleasant to work with as the platform grows.
Leave a Reply