Large Models & Composite Models

When default limits are not enough

Large semantic model storage format

What it does

Feature	Default Format	Large Format
Model size limit	~10 GB (capacity-dependent)	Up to total capacity memory
Segment size	~1 million rows	~4 million rows (larger segments)
Compression	Standard VertiPaq	Enhanced VertiPaq with larger segments
Refresh	Full or incremental	Full or incremental (incremental especially beneficial)

When to enable it

• Your model exceeds 10 GB compressed
• You have fact tables with billions of rows
• You are using incremental refresh (large format works well with incremental refresh, especially for real-time data partitions)
• XMLA endpoint read/write is needed for management tools

How to enable it

1. In the Power BI portal or Fabric workspace, go to Semantic model settings
2. Under Large dataset storage format, toggle it On
3. Apply changes — the model reformats on next refresh

💡 Exam tip: Large format prerequisites

Large format requires:

• Premium or Fabric capacity (P1/F64 or higher) — not available on shared capacity
• Incremental refresh configured (recommended but not strictly required)
• Model must be published to the service (cannot enable in Desktop)

Large format is especially valuable with incremental refresh — only new/changed partitions refresh, keeping refresh times manageable even for enormous models.

Composite models in depth

A composite model mixes storage modes within one semantic model. You saw the concept in the Storage Modes module — here we go deeper.

Architecture patterns

Pattern 1: Direct Lake + Import (most common in Fabric)

Direct Lake tables        Import tables
─────────────────         ────────────
fact_sales (500M rows)    dim_exchange_rates (200 rows)
fact_returns (10M rows)   dim_holidays (365 rows)

Large fact tables stay as Direct Lake (fast, no refresh). Small, slow-changing reference tables are imported for maximum query speed.

Pattern 2: Direct Lake + DirectQuery (cross-source)

Direct Lake tables            DirectQuery tables
─────────────────             ──────────────────
fact_sales (Fabric lakehouse) fact_crm (Salesforce)
dim_product (Fabric)          dim_crm_contacts (Salesforce)

Fabric data via Direct Lake, external CRM data via DirectQuery. One model serves both.

Pattern 3: Import + DirectQuery (classic hybrid)

Import tables                 DirectQuery tables
─────────────                 ──────────────────
dim_product (imported)        fact_realtime (live SQL)
dim_date (imported)
agg_monthly (imported)

Historical aggregates imported for speed; live detail table via DirectQuery for drilldown.

Composite model considerations

Composite models add flexibility but require careful design

Consideration	Impact
Relationship storage	Relationships between different storage modes are 'limited' — some DAX functions behave differently
Security	RLS on Import tables works as expected; RLS on DirectQuery tables is pushed to the source
Performance	Cross-mode joins are slower than same-mode joins. Keep frequently joined tables in the same mode.
Chaining	Users can chain DirectQuery to a published model, creating 'composite models over composite models'

💡 Scenario: James designs a multi-client composite model

James at Summit Consulting builds a composite model for a client that needs:

1. 3 years of sales data (2 billion rows) from a Fabric lakehouse → Direct Lake
2. Live CRM pipeline data from Salesforce → DirectQuery
3. Exchange rates (200 rows, updated weekly) → Import
4. Target budgets (50 rows per department) → Import

The composite model connects all four. Relationship between Direct Lake and DirectQuery tables is “limited” — James places dimension tables shared between both in Direct Lake for best performance.

Question

What does the large semantic model storage format do?

Click or press Enter to reveal answer

Answer

Removes the default per-model size limit (~10 GB) and allows models to grow up to total capacity memory. It uses larger VertiPaq segments (~4M rows vs ~1M) for better compression. Requires Premium/Fabric capacity.

Click to flip back

Question

What is a 'limited' relationship in a composite model?

Click or press Enter to reveal answer

Answer

A relationship between tables with different storage modes (e.g., Import and DirectQuery). Limited relationships may restrict certain DAX functions and can be slower than same-mode relationships. Design tip: keep frequently joined tables in the same storage mode.

Click to flip back

Question

What is a composite model?

Click or press Enter to reveal answer

Answer

A semantic model that mixes tables with different storage modes (Import, DirectQuery, Direct Lake) in a single model. This enables cross-source analytics — e.g., Fabric lakehouse data via Direct Lake combined with live CRM data via DirectQuery — without moving all data into one location.

Click to flip back

Knowledge Check

Raj at Atlas Capital has a semantic model that reaches 15 GB compressed. The model is on an F64 Fabric capacity with a default 10 GB per-model limit. What should Raj do?

AMove to a larger capacity (F128 or higher)BEnable large semantic model storage format to remove the per-model limitCSplit the model into two smaller modelsDSwitch all tables to DirectQuery to avoid size limits

Check Answer

Knowledge Check

James at Summit Consulting builds a composite model with fact_sales (Direct Lake, 2B rows) and crm_contacts (DirectQuery to Salesforce). A report visual joins both tables. What should James expect?

AThe join will fail — Direct Lake and DirectQuery tables cannot be joinedBThe relationship will be 'limited' — the join works but some DAX functions may behave differently and performance may be slowerCThe join will be as fast as a same-mode join — composite models handle this transparentlyDJames must import the CRM data to make the join work

Check Answer

🎬 Video coming soon

---

Next up: Direct Lake Mode — configure Fabric’s recommended storage mode, including fallback behavior and OneLake vs SQL endpoints.