Composite models

What it does

A composite model mixes table storage modes in one semantic model — Import alongside DirectQuery, Direct Lake alongside Import, or DirectQuery against more than one source. Storage mode is a property of each table, set in the Properties pane under Advanced.

Key facts

Storage mode options are Import, DirectQuery and Dual. Dual means the table behaves as either, and the engine picks per query.
Tables are grouped into source groups. Every Import table is a single source group regardless of how many underlying sources fed it, and Direct Lake tables sit in that same source group. Each distinct DirectQuery source is its own source group.
Relationships that cross source groups default to many-to-many cardinality regardless of the real cardinality. You can change the cardinality, but the behaviour stays different — DAX can't retrieve values from the "one" side using functions like RELATED.
Tooling depends on the combination. Import plus DirectQuery is Power BI Desktop only. Import plus Direct Lake is Power BI web modelling only. DirectQuery plus Direct Lake is XMLA only. Direct Lake on SQL can't participate in a composite model at all.
Connecting live to a shared semantic model and choosing Make changes to this model converts the live connection into a DirectQuery connection and creates a local composite model on top.
Calculated tables are always Import, even when they reference DirectQuery tables, so their values are as of the last refresh.
The status bar shows Mixed when a file contains both Import and DirectQuery tables, and you can switch everything to Import from there.
Values from one source get sent to another source inside query predicates. That's a data movement fact, not a theoretical risk.

When to use / skip

The usual good case is a large DirectQuery fact table with dimensions in Dual mode, sometimes with an Import aggregation table over the top — you get in-memory speed for the common queries and current data where it matters. The other good case is extending someone else's certified model with a couple of local tables the central team won't add. Skip it when you're only combining Import sources; that isn't a composite model and doesn't need the ceremony. And be wary of composite as a way to avoid a data warehouse conversation — it works, but you've now got a model whose performance depends on two systems you don't control.

Configuration decisions

Which tables are DirectQuery, which are Import, and which are Dual. Dimensions related to both Import aggregates and DirectQuery facts almost always want Dual.
Whether cross-source-group relationships are acceptable at the cardinality involved, since performance degrades as the joining column's cardinality rises.
Whether report authors are allowed to take DirectQuery copies of the central model, and what that does to your certification story.
Which tooling owns the model, given the tooling matrix effectively decides who can edit it and where.
What the client's position is on values from one source appearing in queries sent to another.

Gotchas

Security is the one people miss. Add a table from Model A into composite Model C, and a user with access to a report on Model C can query any table in Model A that isn't protected by row-level security. That's a permissions design decision, not a footnote.
Query text sent to the relational source can contain values pulled from the other source. Anyone who can read database traces or audit logs can see them, without any permission on the original source.
Watch the encryption settings on each connection. Pulling data over an encrypted connection and then embedding it in a query over an unencrypted one is easy to do by accident.
High-cardinality cross-source joins fall back to querying at lower grain and aggregating locally, and fail outright past a one-million-row limit. Distinct counts grouped by a column from another source can generate one query per group value.
Opening a .pbix from an untrusted source is a genuine risk with composite models — the file's author can arrange for data pulled with your credentials to be sent to a source they control. Power BI warns you; take the warning seriously.
Many-to-many relationships mean totals and subtotals are separate source queries. A simple table with a total row sends two.

Consultant notes

Raise the cross-model security behaviour with the client's security lead in writing. It's the single most likely thing to surface in a review after you've left.
Dual storage mode is the quiet win. Most composite model performance complaints come from dimensions left in DirectQuery when they should be Dual.
If self-service authors are extending the central model, put a policy around it early. Otherwise you get a dozen near-copies of the certified model with slightly different measures.
Test at realistic concurrency. Composite models can look fine with one user and fall apart when twenty people open the same page at 9am.

Recheck the tooling matrix if Direct Lake composite support moves — the Desktop, web modelling and XMLA split has already shifted more than once.