Mosaic Model Linking: Querying across data sources without merging them

If you've worked in a semantic layer, you know the two usual options. You either go down to the warehouse and physically join the source tables — which means a schema change, a maintenance burden, and a ticket that sits in someone's queue for a sprint or two. Or you build a third model that copies metric logic out of the first two, which means you now have three definitions of "revenue" to keep in sync and a fresh way for your numbers to stop reconciling.

Model Linking is Mosaic's answer to that, and to understand why it works the way it does, it helps to start with a constraint that the marketing pages tend to skip over.

A single Mosaic model binds to one live data source. That's not a limitation someone forgot to remove — it's load-bearing.

Live models in Mosaic are pass-through. When a query lands, Mosaic resolves the metric definitions, tables and join paths, and security filters, then pushes the actual execution down to the source using the source's own credentials. That pushdown is exactly what lets row-level and column-level security from the warehouse follow the query through Mosaic without anyone re-implementing it. The model trusts the source to enforce what the source already enforces.

The moment you try to make one live model span two sources, that contract breaks. Snowflake and Databricks don't share a credential, a security model, or a query engine. So Mosaic draws the line at one live source per model and federates between models instead of trying to cram two sources into one.

That's the real job of Model Linking. It isn't primarily a workflow shortcut — it's the supported mechanism for multi-source federation. If your HR data is a live model on Snowflake and your finance data is a live model on Databricks, linking them is how you query both in a single view. There is no other path that keeps the governance intact.

One model, one source. Linking joins them at the semantic layer instead of in the warehouse.

A link is an attribute-level connection between two models, defined once in Mosaic Studio and resolved at query time. Nothing moves. No table gets merged. The link is a logical relationship that Mosaic's engine — which leans on Trino for SQL parsing, planning, and federation — applies when the query runs.

A warehouse join rewrites your data structure. A model link is a relationship the engine applies at query time.

Concretely: you pick the joining attribute on each side — say Customer (customer_id) in the sales model and Customer (cust_id) in the finance model — give the linked attribute an alias, point it at the lookup table that supplies its values, and apply. From then on the combined model treats that joined dimension as a single queryable attribute, and metrics from both models show up in one namespace. A dashboard or an AI agent built on top doesn't need to know it's reaching across a domain boundary.

The same pattern handles the shared dimensions that show up everywhere — Employee, Time, Product. Model the link on those once and every domain that owns one of those entities can be queried against the others.

You have three ways to create a link, and they're worth knowing because they suit different situations:

• AI-assisted suggestions.
  Mosaic Studio scans attributes across your models and proposes likely links. They show up in the Models view as dashed lines; confirmed links are solid. Click one, check that it picked the attributes you expected, set the alias and value source, apply. This is the fast path when the relationship is obvious from the data — matching keys, matching names.

• Manual creation.
  The Manage Links panel lets you define a link explicitly: the model and attribute on each side, an alias, a value source. Reach for this when the AI doesn't have enough signal to spot the relationship, or when the join you want isn't the one it would guess.

• Import-time linking.
  When you bring an existing model in, you can establish the link as part of the import, so the model arrives already connected rather than getting wired up afterward.

The Models view is the part you'll live in. It's a graph of your models and their connections — solid for what's confirmed and dashed for what's suggested — and it's the fastest way to see whether the cross-domain shape you have in your head matches the one that's really wired up.

So far we've treated linking as a way to answer a question that spans two domains. The more durable payoff shows up when you stop treating every model as a finished destination and start treating some of them as building blocks — things you author once and link into everything else.

The first shape is a shared hierarchy. A clean Time dimension with its calendar logic, a Product hierarchy with its category rollups, an Org structure that maps people to teams to cost centers — each is real modeling work, and none of it is work you want to redo in every domain model that happens to need it. Build it once as its own model, get the rollups and member ordering right, then link it into the sales model, the finance model, the supply-chain model. Every consumer inherits the same hierarchy, and when the reorg lands you fix it in one place instead of five.

The second is a metrics-and-keys model: a model that's essentially a governed metric library plus the entry-level attributes needed to join to it. Revenue, margin, and bookings defined once, sitting next to the customer and date keys that let other models reach them. A team that needs revenue in their view doesn't re-derive SUM(sales_amount) and hope it matches finance's number. They can link the metrics model in and pull the canonical definition through. The metric has one home, and everyone who links to it gets that home's answer.

Both patterns turn linking into a way to extend a model rather than rebuild one. Need the sales model to also speak in fiscal periods and report margin? Link the time hierarchy and the metrics model, and it can suddenly do both without copying a single definition. The capability arrives by reference, not by duplication.

This holds up for the same reason the cross-domain story does: the link resolves at query time and the definition stays in one place. A reused metric isn't a copy that can drift; it's the original, surfaced through the link. Governance comes along too — a user still needs access to the underlying attributes in the shared model to see anything it contributes, so reuse never quietly widens who can see what.

One thing to keep honest: a building block is still a model. It binds to one live source, or it's in-memory — in which case you configure its security in Mosaic directly — and linking it widely means its definitions and its performance now matter to every model downstream. That's the upside and the responsibility of a shared asset: get the grain right, because everyone is about to depend on it.

This is the question a security reviewer will ask first, so it's worth being precise. Linking does not create a backdoor.

For row-level security, the security filters defined on each model will also propagate to all linked models, ensuring that the strictest governance is applied when models are connected.

For object-level security, when attribute A1 in one model links to A2 in another and gets exposed as linked attribute A3, access is additive: a user has to be able to see both A1 and A2 to use A3. Lose access to either underlying attribute and the denial propagates to the linked one automatically. The permissions defined in the original models carry forward — you don't reconfigure anything on the linked model.

Access to the linked attribute requires access to every attribute beneath it. One missing permission denies the whole linked view.

The reason this matters more for linked models than for single ones is that linking is where the dangerous combinations get created. Link a revenue metric to a headcount metric, and you've built a path that could surface salary-adjacent numbers to someone who has overall revenue access but was never meant to see anything from HR. Additive enforcement is what keeps that path closed: revenue access alone isn't enough — you need the HR side too, and if you don't have it, the linked view simply won't return it.

A few things to keep honest about, because they shape how you design:

Data federation has a cost. Resolving a query across two sources is real work, and cross-source joins won't match the speed of a single live or in-memory model. This is usually fine, but it's a design input, not a free lunch — don't promise zero-latency federation to anyone.

A link is only as good as its keys. If the joining attributes don't actually correspond — mismatched grain, fuzzy identifiers, IDs that mean different things on each side — the link will produce results, just not correct ones. The AI suggestions help here, but confirming the join semantics is still a human job.

And linking is for connecting clean, domain-owned models — not for papering over models that should have been built better in the first place. The discipline that makes each domain model authoritative is what makes linking them safe.

The full technical documentation walks through each step: creating links, editing them, managing the Models view, and understanding time attribute behavior across model boundaries. Start with the creation guide.

Create New Mosaic Model Links

View Mosaic Model Links

Time Attributes in Mosaic Model Links