Microsoft Fabric Architecture: OneLake, Capacity, and the Move from Synapse

A team running a Synapse workspace asks whether to move to Fabric, and the question sounds like a version upgrade. It is not. The two are different shapes of product: one is a set of Azure resources you provision, size, and pay for individually; the other is a SaaS platform where every workload draws on a single pool of compute and a single lake. Most of what surprises people after the move follows from that one difference rather than from any particular feature.

This article describes both as documented on September 15, 2026, and concentrates on the parts that change decisions: how Fabric’s layers fit together, what a capacity actually is and what happens when it runs out, what coupling Power BI into the platform does to permissions and contention, and what a Synapse warehouse actually loses and gains on the way across. Microsoft’s own throttling documentation says the policy may change, so treat the structure as durable and every number as dated. Examples are invented, and no prices appear here.

The shape of Fabric

Fabric is delivered as software as a service. Rather than a catalog of services you assemble, it presents a set of role-oriented workloads over a common platform layer. The documented workloads include Power BI, Databases, Data Factory, Industry Solutions, Real-Time Intelligence, Data Engineering, Data Science, Data Warehouse, and Fabric IQ, which is in preview. Beneath them sit shared services: OneLake for storage, Copilot, and governance including permissions, sensitivity labels, and auditing.

Three structural facts do most of the work in any design conversation, and they are easiest to hold as a hierarchy of nouns.

Level	What it is	What it decides
Tenant	One Microsoft Entra tenant, with exactly one OneLake	Tenant-level policies apply to anything that lands in OneLake
Capacity	A distinct resource pool, bought as an F SKU, tied to a region	How much compute exists, what is billed, and — through the region — where the data sits for residency purposes
Workspace	A container for items, assigned to one capacity	Ownership, access, and which capacity pays
Item	A lakehouse, warehouse, notebook, pipeline, semantic model	Which engine and which storage shape

The relationship worth noticing early is that a workspace belongs to a capacity, and a capacity is a pool. That single line is where the operational character of the platform comes from, and the capacity section returns to it.

OneLake: one lake, by construction

Every Fabric tenant automatically includes OneLake, and the documentation is unusually direct about the constraint: you cannot delete OneLake or create multiple OneLakes, and there is no infrastructure to provision. It is built on Azure Data Lake Storage and stores tables in Delta Parquet or Iceberg — the table format layer that lets several engines agree on what a table is. Workspaces appear as containers and items as folders to anything speaking the ADLS Gen2 APIs, which is how existing Azure tools reach it.

The design goal is one copy of data that several engines read. Because T-SQL, Spark, and Analysis Services all store in the open Delta Parquet format, a warehouse built by SQL engineers can be read by a Spark notebook without an export or a connector, and both operate on the same files. Two features extend that principle outward, and they are worth distinguishing because they fail differently.

• Shortcuts are references to data held elsewhere — another workspace, ADLS, Amazon S3 and S3-compatible sources, Iceberg-compatible sources, Dataverse, on-premises sources. The shortcut points at the source rather than loading a second copy of it, and schema changes at the source are synchronized without manual intervention — though the documentation notes that propagation time can vary with data source performance, cached views, and network connectivity. External shortcuts can also cache: OneLake stores files read through them for a retention period you set between 1 and 28 days, to reduce cross-cloud egress cost. The cache is not a staleness trap, because OneLake serves from the remote provider and refreshes the cached copy when the remote version is newer — but it does mean “nothing is copied” is the wrong summary. The accurate one is that there is one authoritative copy, at the source, and no separate dataset for anyone to reconcile.
• Mirroring makes an external database or catalog available through OneLake without your building pipelines. It comes in two forms that differ in exactly the way that matters: database mirroring continuously replicates an operational database into OneLake as Delta tables, while metadata mirroring synchronizes a catalog and uses shortcuts to read the open-format data in place. Database mirroring is also priced unusually: the replication compute is free and does not consume capacity units, and each capacity unit purchased includes a terabyte of free mirroring storage — but the capacity has to be running, because a paused or deleted capacity stops replication.

Two shortcut behaviors belong in a design review rather than in a later incident. Deleting a shortcut leaves the target untouched, but deleting a file inside a shortcut deletes it at the target when the user has write permission there — so a cleanup inside Fabric can remove someone else’s source data. And shortcuts are bounded: the documentation states a limit of 10 shortcuts per path and 100,000 per item, which matters for any design that plans a shortcut per customer or per day.

The distinction is the familiar one between a reference and a copy, and it carries a familiar consequence — stated carefully. Where data is replicated, there is an independent copy that can drift from its source and has to be kept in step. Where it is referenced, that particular problem goes away, because there is no second dataset to reconcile. What does not go away is latency: metadata and schema synchronization has a propagation time that varies with the source, the network, and cached views, and each consuming engine still refreshes on its own terms. The source’s availability and performance are also in your read path now. So the reference option removes the synchronization of an independent replica, not delay in general, and the question remains which failure you would rather explain.

Security can be defined once at the lake rather than per engine. OneLake security roles grant access down to folders, tables, rows, and columns, and OneLake enforces them across analytics experiences, so a restriction applies whether the user arrives by SQL, a Spark notebook, or a Power BI report. For anyone who has maintained parallel permission sets across three engines, this is the most valuable property in the platform.

Two engines need a configuration choice before they honor it, and both are worth setting deliberately rather than discovering. The SQL analytics endpoint reads OneLake-secured data when it is switched to user’s identity access mode. A semantic model honors it when it uses Direct Lake on OneLake. Queries that arrive from engines OneLake does not recognize are treated as user access instead: if the user is not permitted to see every row and column, the query is blocked rather than filtered — a stricter outcome, and a better default than silently returning everything.

Capacity: one pool, and what happens when it empties

A capacity is a resource pool sized in capacity units. F SKUs run from F2 to F8192, are bought through Azure, and are billed per second with a one-minute minimum and no commitment, with a reservation available for savings. Any workspace in the tenant can be assigned to any capacity.

What makes the model distinctive is how it handles spikes. Bursting lets an operation temporarily use more compute than the SKU provides, so a query is not slowed to fit the size you bought. Smoothing then averages that consumption forward across future timepoints, which are 30 seconds long — 2,880 of them in a day. Interactive operations are smoothed over a minimum of five minutes and up to 64, depending on consumption; background operations are smoothed over 24 hours. The practical effect is that scheduled jobs can all run at once without producing a spike that blocks anything, which removes a scheduling chore that other platforms impose.

It also means the bill and the contention are both shared. When sustained demand exceeds what smoothing can absorb, the capacity throttles, and it does so in stages rather than all at once.

Future capacity consumed	Stage	What users see
Up to 10 minutes	Overage protection	Nothing. Jobs consume future capacity without throttling
10 to 60 minutes	Interactive delay	New interactive jobs are delayed 20 seconds at submission
60 minutes to 24 hours	Interactive rejection	New interactive jobs are rejected; background jobs still start
Over 24 hours	Background rejection	All new requests are rejected

Two details soften this and are worth knowing before an incident. Operations already running are never throttled — throttling applies only to requests submitted after it begins, so long jobs complete. And capacities are self-healing: unused capacity burns down the accumulated debt, and waiting is a legitimate response. When waiting is not acceptable, the documented levers are raising the SKU temporarily so each timepoint has more idle capacity, pausing and resuming the capacity, or enabling overage billing, which costs three times the normal rate. Pausing deserves care on two counts: it triggers a billing event for the accumulated future capacity usage, and it can make content on that capacity unavailable.

A few workloads are documented as exceptions, and they reveal the reasoning. Real-Time Intelligence skips the 20-second delay stage entirely — a real-time product that delays by 20 seconds is not one — and begins throttling only at the rejection stage. Nearly all Warehouse operations are classified as background so that they receive 24-hour smoothing and do not trigger throttling too quickly. Eventstreams, which may run for years, are not rejected at all; instead the CU allocated to keeping the stream open is reduced until the capacity recovers.

Read as an architecture rather than a billing scheme, a capacity is both a budget and a blast radius. Everything assigned to it competes for the same pool, so a heavy Spark job and an executive dashboard on one capacity are two tenants of one resource — multi-tenancy inside your own organization, with the noisy neighbor problem that comes with it — and resource exhaustion in the first is visible in the second. The staged throttling is a form of backpressure — the system protecting itself by refusing work rather than degrading everything — and like all backpressure it pushes the problem to whoever submitted the request.

That makes capacity assignment an isolation decision first. It is an accounting one too, because a capacity is the unit the bill arrives for: attributing cost to a team means either giving it its own capacity or apportioning a shared one from the metrics. Fabric applies throttling per capacity, and other capacities continue running normally, so a second capacity is the mechanism for workload isolation here, in the same role that a separate warehouse or cluster plays on other platforms. The trade is the familiar one: separate capacities isolate, and pooled capacity is cheaper because one pool absorbs uncorrelated peaks. A defensible default is to separate by what you would not want delayed — production serving apart from exploration and development — rather than by department, and to leave things pooled where a 20-second delay would go unnoticed. One caution if you scale rather than split: the documentation warns that scaling between SKUs on opposite sides of the F256 and F512 boundary might result in a slower experience.

Sizing follows from the same shape. Because utilization above 100% does not by itself mean throttling, the number to watch is not peak utilization but whether smoothed usage crosses a throttling limit, which the capacity metrics app reports directly along with minutes to burndown. Sizing on peaks buys capacity that smoothing would have handled.

What bundling Power BI actually changes

Power BI is not an add-on here; it is one of the workloads, and it draws on the same capacity as everything else. Three consequences reach beyond the BI team.

Reporting competes with pipelines. A report refresh and a nightly load are both operations against the same pool. Compound throttling protection limits how often a single chain of calls is throttled, but it does not separate the workloads — only a separate capacity does that.

A threshold at F64 shapes who can read what. On F SKUs smaller than F64, every user viewing Power BI content needs a Pro or PPU license; on F64 or larger, a user with a Free license and a viewer role can view it. Non-Power BI Fabric items behave differently: a Free license can create and share those in any F or Trial capacity workspace. So the cost of broad report readership is a step function, not a slope, and the step sits at a specific SKU. Worth knowing in the opposite direction too: PPU does not provision a Fabric capacity, so a team licensed entirely through PPU cannot create lakehouses, warehouses, or notebooks without an F capacity.

Direct Lake changes what a refresh is. Direct Lake is a semantic model storage mode that loads Delta tables from OneLake into memory and is queried by the same VertiPaq engine as Import mode. The difference is the refresh: an Import refresh copies the data, while a Direct Lake refresh copies only metadata — an operation called framing that updates references to the latest files and can take a few seconds. For a medallion gold layer, this removes an entire category of scheduling and a large recurring compute cost.

It comes with capacity-linked guardrails that are worth reading before committing: per-SKU limits on Parquet files per table, row groups per table, rows per table, and model size on disk. At F64, for instance, the documented guardrails are 5,000 Parquet files and 5,000 row groups per table, and 1.5 billion rows per table. Exceeding one has a consequence that depends on which Direct Lake variant is in use, and the two behave differently enough to be treated as separate choices: Direct Lake on OneLake fails the refresh, and the model cannot be queried until the Delta tables are optimized, while Direct Lake on SQL falls back to DirectQuery if fallback is enabled, so queries still return, more slowly. One fails loudly, the other degrades quietly, and neither is the right default for every model.

Max memory is listed in the same table and is deliberately not one of those guardrails. The documentation is explicit that it is an upper limit on how much data can be paged in rather than a guardrail, so crossing it produces slower queries from excessive paging in and out of the model data, not a refused refresh or a fallback. At F64 the documented figure is 25 GB. Treat it as a performance budget you can overrun at a cost, and the others as thresholds that change the model’s behavior — and note that model size on disk is evaluated at the model level and affects all queries, while the other guardrails are evaluated per query.

The same pair differs in a way that belongs to security review rather than performance tuning, and getting it right depends on keeping two separate policies separate. Row-level security can be defined in OneLake, or at the SQL analytics endpoint, and they are enforced by different engines.

Where the rule is defined	Direct Lake on OneLake	Direct Lake on SQL
OneLake security roles (RLS/CLS)	Enforced in memory — this is the documented mode for reading OneLake-secured data	Requires the SQL analytics endpoint in user’s identity (SSO) mode, and then falls back to DirectQuery 100% of the time
Row-level security at the SQL analytics endpoint	Not applied. Queries succeed, because this mode reads the files in OneLake, which do not observe SQL-based RLS	Observed — queries fall back to DirectQuery

Read the second row rather than the first as the warning. A filter authored at the SQL endpoint is not a control that holds on every access path, because a supported semantic model mode reads past it. That is not a hole in OneLake security; it is what happens when a rule is defined at one layer and readers arrive through another. The general form is worth carrying to any platform: the enforcement point has to be the layer everyone reads through, which makes it a question about ownership and where a definition lives rather than a setting to toggle. Concretely here, define the restriction in OneLake if it must hold for everyone, and confirm the access mode on each engine that reads it.

Two consequences of that table are easy to miss and expensive to discover. First, the configuration that makes the SQL path honor OneLake security is not free: when a lakehouse’s SQL analytics endpoint is switched to SSO, the documentation states that OneLake security roles become SQL granular access control rules and Direct Lake on SQL then falls back to DirectQuery 100% of the time. Enforcing the rule on that path therefore costs the in-memory performance that was the reason to choose Direct Lake — which is a real trade, not a setting, and it is the argument for putting such models on Direct Lake on OneLake instead.

Second, “the user’s permissions” is itself a configuration. By default a Direct Lake model uses single sign-on and evaluates the identity of whoever is querying; bound to a cloud connection with a fixed identity instead, it evaluates that identity’s permissions for everyone. Per-user rules only do anything under the first arrangement. A model on a fixed identity with row-level security defined upstream gives every viewer the same rows — correct behavior for a read-only consumer scenario scoped to one service account, and a silent hole if someone expected per-user filtering. Whenever a policy is described as per-user, check which identity the model actually evaluates.

Synapse, and what it is today

Azure Synapse Analytics brings several engines under one studio: Synapse SQL in both dedicated and serverless resource models, Apache Spark, and the same data integration engine as Azure Data Factory for pipelines. One component that appears in older descriptions is gone — Azure Synapse Analytics Data Explorer, which was in preview, was retired on October 7, 2025, with Microsoft’s migration guidance pointing at Eventhouse in Fabric. Component-level retirements and the product’s overall support status are separate facts, and this is the clearest illustration of why both have to be checked rather than inferred from each other.

The two SQL resource models are the contrast worth carrying into a comparison, and they differ more than the shared name suggests.

• A dedicated SQL pool reserves processing power for data stored in SQL tables, which is what gives it predictable performance and predictable cost. You choose the size, and you are paying for the reservation.
• A serverless SQL pool is a query service over data in the lake, and the documentation is direct about the consequence: there is no infrastructure to set up or clusters to maintain, a default endpoint is provided in every workspace, there is no charge for reserved resources, and you are charged only for the data processed by the queries you run. It has no local storage — only metadata objects live in its databases — so it queries files in place rather than holding tables.

That pairing is the useful thing to compare against Fabric, because it is a third billing shape alongside the two already described. A dedicated pool is a reservation you size. A Fabric capacity is a shared pool you size, with bursting, smoothing, and throttling deciding what happens at the edges. A serverless pool is neither: nothing is sized and nothing is reserved, and the bill follows bytes scanned — which makes query efficiency a direct cost lever rather than a performance one, and makes an unpartitioned lake expensive in a way no capacity setting would reveal.

On its status, the primary source to cite is the lifecycle page rather than commentary. As of September 15, 2026, Microsoft’s lifecycle listing for Azure Synapse Analytics shows it following the Modern Lifecycle Policy with a retirement date of “In Support” — that is, no retirement date is published. Anyone planning around an assumed end date should check that page rather than rely on this one, since the answer is exactly the kind that changes.

One observation can be made without inference: on the date checked, the Synapse overview page carried a documentation date of July 10, 2024, while the Fabric pages cited here carried dates in 2026. Differing documentation cadence is a fact about the documentation. It is a reasonable prompt to verify feature currency before depending on a Synapse capability, and not a basis for predicting the product’s future.

Moving a dedicated SQL pool across

Microsoft’s migration guidance is worth reading for the specifics, but four differences account for most of the surprises.

• Physical tuning does not travel. Typically only raw data and metadata migrate; elements such as indexes usually are not moved, because they may be unnecessary or implemented differently, and Fabric handles that optimization automatically. The guidance suggests reading the existing optimizations as a map of where performance mattered rather than as objects to recreate.
• T-SQL is not identical. There are DML syntax differences against the documented T-SQL surface area of Fabric Data Warehouse, and depending on the parity gap at the time, parts of the code may need rewriting. This is the line item that a code assessment sizes, and the one most often underestimated because the language name is the same.
• Some data types change, and one of them loses information. The documented mappings include money to decimal(19,4), nvarchar to varchar, tinyint to smallint, and datetime to datetime2. The one to inspect by hand is datetimeoffset: it maps to datetime2, which does not store the time zone offset, so that offset must be extracted into a separate column. A silent loss of offset is the kind of defect that surfaces months later in a cross-region report.
• The cost model stops being a reservation. A dedicated pool reserves capacity for a workload. A Fabric capacity is shared across every workload assigned to it, with bursting, smoothing, and throttling in between. Performance work shifts from sizing one pool to deciding what shares a capacity — which is the section above, and a genuinely different skill.

On approach, the guidance names two, with the conditions that favor each. Lift and shift migrates the existing model with minor changes and suits a small number of warehouses, data already in a well-designed star or snowflake schema, and time or cost pressure. A phased modernization with architectural changes suits a warehouse that has accumulated over years and would need re-engineering to hold its performance. The runbook that follows is conventional and effective: assess and baseline, plan and design, migrate schema then data then code, run in parallel and compare against the source, and only then move applications and reporting. Running in parallel is the step teams cut when schedules slip, and it is the step that produces the evidence that the new system agrees with the old one — a reconciliation against the source at an agreed cutoff, rather than a look at two dashboards. The period in which both run is coexistence and the moment applications switch is the cutover; naming them separately keeps the decision to switch from being made by whoever is most tired — the same discipline any modernization needs.

Questions that reveal the wrong choice

Question	If the answer is unclear
Which workspaces share a capacity, and would you accept one delaying another?	A batch job throttles a dashboard, and the fix is discovered during the incident
Does your sizing look at peak utilization or at the throttling limits after smoothing?	Capacity is bought for spikes the platform was going to absorb
Who is notified when a capacity starts throttling, and what are they authorized to do?	Users see rejected requests before anyone with a lever knows
Is your Power BI readership above or below the F64 threshold, and what does that cost either way?	A licensing step function is discovered after the SKU is chosen
For each Direct Lake model, which variant is it, and what happens when guardrails are exceeded?	A model fails hard, or silently degrades, and nobody predicted which
Where is row-level security enforced, and does it hold on every path readers actually use?	A filter defined at the SQL endpoint is bypassed by a supported access mode
For each external dataset: shortcut or mirror, and why?	A replication lag or a source dependency exists that nobody chose
In a Synapse move, which columns are datetimeoffset?	Time zone offsets are dropped quietly during the migration

References

All sources were checked on September 15, 2026, and the documentation dates shown on each page at that time are noted below. Microsoft’s throttling documentation states that the throttling policy may change; capacity behavior, licensing thresholds, guardrails, and product lifecycle status should be confirmed against current documentation before relying on any of it.

• Microsoft Learn, What is Microsoft Fabric? (documentation date March 18, 2026)
• Microsoft Learn, OneLake, the unified data lake (March 9, 2026)
• Microsoft Learn, Unify data sources with OneLake shortcuts (July 13, 2026)
• Microsoft Learn, Read data secured with OneLake security (August 28, 2026)
• Microsoft Learn, Understand Microsoft Fabric licenses and capacity (June 15, 2026)
• Microsoft Learn, Understand capacity throttling and smoothing (August 14, 2026)
• Microsoft Learn, Direct Lake overview (June 15, 2026)
• Microsoft Learn, Integrate Direct Lake security (September 22, 2025)
• Microsoft Learn, What is Azure Synapse Analytics? (July 10, 2024)
• Microsoft Learn, Serverless SQL pool in Azure Synapse Analytics (September 12, 2024)
• Microsoft Learn, Migrate from Azure Synapse Data Explorer to Fabric (March 26, 2025)
• Microsoft Lifecycle, Azure Synapse Analytics
• Microsoft Learn, Migration Strategy and Planning for Azure Synapse Dedicated SQL Pools to Fabric Migration (March 16, 2026)