Azure Analysis Serves AAA data model migrated to Fabric Semantic model issue

Hi nvmtrang , F64 supports a maximum 25 GB semantic model size per model and 25 GB memory, which is not per model but per session capacity and a In-memory working set during refresh or query of 12.5 GB (half of 25 GB). 

#2. Is splitting the semantic model into multiple, smaller models the only supported option? > Answer is that the alternatives narrow to only two: 

• #Option 1. Optimize & split your model into smaller semantic models, each ≤ 25 GB.
• #Option 2. Scale-up Fabric capacity supporting much larger models F128 = 50 GB, F256 = 100 GB 

Hope I answer your questions! It seems like you already suspecting this would be the answer, but still, is wise to confirm on the community, best of lucks with the migration, I hope your company can afford the F128 😅🤞! 

Best of lucks and I would appreciate a kudos and for you to mark this as a solution... cheers and best of lucks 

Hi nvmtrang ,

Let's get straight to the solution.

The Direct Answer: No. You strictly cannot fit a 34 GB model into an F64 capacity (limit is 25 GB). It will fail to load into memory.

The Practical Solution (Don't Split, Shrink!) Before you spend double the money on an F128 or complicate your architecture by splitting the model, you should perform Aggressive Optimization. A 34 GB legacy AAS model usually contains 30-40% "wasted space" (bloat). Reducing it to <25 GB is highly realistic.

Here is your 3-Step Action Plan to fit this model into F64:

1. Audit with VertiPaq Analyzer (DAX Studio): Look at your top 5 largest columns. They likely consume 80% of your memory.

2. Target High Cardinality: Do you have text columns with unique values (like InvoiceID, TransactionGUID, or AuditLog)?

   • Action: If they are not used for grouping, remove them. If they are used for relationships, convert them to Integers in the ETL. This step alone can often save 5-10 GB.

3. Split DateTime: Do you have Timestamp columns?

   • Action: Split them into two columns: one for Date and one for Time. Storing them as a single DateTime column is extremely expensive for the engine.

Recommendation: Invest time in optimization first. If you can shrink it to 24 GB, you save the migration without upgrading. If you cannot shrink it, you must upgrade to F128. Splitting the model should be your absolute last resort.

If my response resolved your query, kindly mark it as the Accepted Solution to assist others. Additionally, I would be grateful for a 'Kudos' if you found my response helpful.
This response was assisted by AI for translation and formatting purposes.

Hi nvmtrang, 

In addition to what svenchio mentioned, it’s worth considering whether you want to do a true lift-and-shift of your Analysis Services model into Fabric, or whether this migration is the right moment to rethink the model altogether. Your AS model is likely well designed, but even though Fabric can handle migrated AS models, it is a different platform with different capabilities and trade-offs. That means it’s useful to reassess your options rather than assuming a one-to-one move.

• If your model includes many years of detailed historical data, it may become very large. For models mainly used by operational users, consider limiting detailed data to the current year and the previous year. This is often enough for operational comparisons.

• If detailed data for several years is still required, think about migrating the Analysis Services model to a composite semantic model. This allows you to combine Import and Direct Lake storage modes for better performance and flexibility.
• If most users only need summary data and only a few require detailed data, consider creating two models: one for summary information and another for detailed data. This can improve efficiency and user experience.
• Before taking any of these steps, revisit your business users to confirm their reporting needs and ensure your model still supports their decision-making requirements.

Another important consideration is model optimization. There are many resources available on reducing model size, but here are five practical steps you can start with:

1. Analyze model size using DAX Studio to identify the largest tables and columns. Focus on areas where optimization will have the biggest impact.
2. Use integer surrogate keys instead of text keys to reduce storage requirements.
3. Remove or refactor calculated columns. Whenever possible, move this logic to Power Query or the data source.
4. Delete unused columns and legacy attributes that no longer serve a purpose.
5. Reduce the column cardinality by:
   • splitting datetimes into date/time keys
   • normalize repeating text into dimensions
   • reduce numeric precision where feasible.

Hope this helps. If so, please give kudos ‌‌👍 and mark as Accepted Solution ‌‌✔️ to help others. If you resolved your question, let us know what worked for you.

Hey burakkaragoz  this is truly and exceptional response and all of your suggested optimization plan I WOULD STRONGLY RECOMMEDN ANYONE TO FOLLOW!  Kudos for this information. 

My follow-up reflection is this nvmtrang , let's say you manage to reduce the model down to 24 GB (almost 9 GB!), you will ANYWAY will not have any space to grow! Remember, the 25GB limitation is not per model but per capacity. So, having a 34 GB model suggest is a big one and I can only assume, it will keep growing overtime, sooner rather than later, you'll hit the 25GB limit and back to square one. 

Just saying it will a good time to push for a higher SKU in addition to all the optimization recommendations. 

svenchio burakkaragoz nielsvdc Thank you all for your replies. We intend to perform a lift-and-shift migration using the Fabric Migration Assistant without optimization activities (no size reduction or model splitting at this stage). Our strategy is to:

1. Initially provision F128 capacity to successfully complete the migration using the Migration Assistant

2. Convert to Direct Lake mode to query directly from OneLake

3. Scale down to F64 capacity post-migration to optimize costs

Given our 34GB model size (Data scope 2 years, 55 dimension tables, 75 fact tables, 3,000 measures), is it viable to scale down from F128 to F64 after migration? Are there any constraints, risks, or best practices we should be aware of when doing this (for example: minimum recommended SKU relative to model size, known performance issues, or unsupported scenarios after scaling down)?
Thank you 😁

It might not be viable, as Direct Lake still uses memory while it loads required segments/columns from Delta tables into memory on demand. Large queries can quickly consume available memory on the F64. Then Direct Lake will automatically fallback to DirectQuery mode, which is not beneficial for you model's performance.

This is not something you can test yourself or with a couple of users. This is something you can only experience in production or create an automated simulation using scripting of a large amount of "users" requesting data from the composite model.

Check this Microsoft article Understand Direct Lake query performance - Microsoft Fabric | Microsoft Learn

Check this article how to maybe create a simulation and also to "warm-up" your model Exploring Direct Lake Framing and warm-up data using Semantic Link in Fabric Notebooks – Data – Marc

Hope this helps. If so, please give kudos 👍 and mark as Accepted Solution ✔️ to help others.

Hi nvmtrang ,

Your strategy is creative ("Lift & Shift to F128" -> "Convert to Direct Lake" -> "Scale Down"), but scaling down to F64 with a 34 GB unoptimized model carries significant operational risks.

While Direct Lake manages memory differently than Import mode (by paging columns in and out), you are walking a very thin line.

Here is the breakdown of the risks and constraints you asked about:

1. The "Fallback" Risk (Performance Cliff) As @nielsvdc correctly warned, Direct Lake is not magic. It loads data into memory on demand.

• The Risk: If a specific report page or DAX query requires a set of columns that exceeds the available memory of the F64 capacity (approx. 25 GB), Fabric will automatically fall back to DirectQuery mode.

• The Result: Performance will drop instantly from "milliseconds" to "seconds/minutes," as it tries to query the Delta Parquet files directly without the in-memory cache. With 3,000 measures and 75 fact tables, the chance of a complex query triggering this fallback is high.

2. The "No Room to Breathe" Issue @svenchio makes a valid point about growth.

• Even if your current "Working Set" (the active data users query) fits into 24 GB, you have zero buffer.

• Any slight increase in data volume, or a user creating a "wide" visual that pulls in a few extra columns, could crash the report or trigger throttling. F64 is an "Interactive" SKU, meaning it is sensitive to "Bursts." A heavy model on a light SKU is a recipe for frequent throttling delays.

3. Direct Lake "Eviction" Behavior On smaller capacities like F64, if the system needs memory for other operations (like a Dataflow refresh or another user's query), it will aggressively evict your Direct Lake model from memory.

• The Impact: The next user who opens the report will experience a "Cold Start" penalty while the columns are loaded back into memory from OneLake. On F128, you have more RAM, so models stay "Hot" longer.

My Recommendation: Do not budget for F64 yet. Keep F128 as your approved baseline. Only scale down to F64 IF you perform the "Aggressive Optimization" I mentioned earlier (removing high cardinality columns, splitting datetime, etc.) after the migration.

Attempting to run a 34 GB unoptimized model on F64 is technically possible with Direct Lake (due to paging), but operationally, it will likely result in a poor user experience due to fallback and eviction.

Hope this helps you manage the expectations with your stakeholders!

If my response resolved your query, kindly mark it as the Accepted Solution to assist others. Additionally, I would be grateful for a 'Kudos' if you found my response helpful.
This response was assisted by AI for translation and formatting purposes.