Semantic Layer for Embedded Analytics: One Definition Across Many Tenants

A semantic layer gives a product one definition for each metric and builds queries from that definition. Inside a multi-tenant analytics product, running one well means three jobs at once: keep one shared definition per metric across all customers, let customers extend it without copying it, and change a definition without silently changing the numbers on dashboards customers have already built.

For an introduction, see the semantic layer glossary entry.

Why One Definition per Metric Matters More When Customers See the Number

Thoughtworks places the semantic layer in the Trial ring of its Technology Radar and describes the problem it addresses plainly: without one, "metric definitions quietly diverge". Uber built its uMetric platform because several versions of the same business metric existed across teams, and people "tend to draw different conclusions based on the version of the metric they consumed".

dbt, Databricks and Snowflake each ship shared metric definitions:

• dbt. "If a metric definition changes in dbt, it's refreshed everywhere it's invoked", across every tool that queries it.
• Databricks. Metric views separate a measure from the fields it is grouped by: "you define the metric once" and choose the grouping at query time.
• Snowflake. Defining semantic views became generally available in June 2025.

A shared definition also needs an owner. In dbt Labs' 2026 survey of 363 respondents, "ambiguous data ownership remains a challenge for 41% of respondents". Thoughtworks recommends starting with a single domain instead of an enterprise-wide rollout.

Three Ways to Give Tenants Their Own Model

Products can combine these three model arrangements:

Microsoft's own guidance on the first arrangement says a single model with row-level security "can be convenient for ISVs that have relatively few customers and small to medium-sized semantic models". For separate models, Microsoft lists "updating the semantic model schema for some or all tenants" as an operation the provider has to manage. In Power BI, dynamic binding lets you connect the same report to different semantic models depending on the user's credentials, so one report can serve every tenant's model.

In Cube, context_to_app_id gives each tenant its own compiled data model, but the documentation notes that it "scopes multitenancy to data model compilation only"; query queues and caching need their own settings.

Let Customers Extend a Definition Without Copying It

Copying a metric for one customer creates two definitions of the same metric, the problem Uber described.

The extension mechanisms in the table keep the parent definition in one place:

• Omni. "Changes to a parent model propagate to all extensions automatically." A change made in an extension stays in that extension.
• GoodData. A child workspace inherits the parent's model, which is "available in its child workspaces in read-only mode"; the child can only add objects of its own.
• Looker. A refinement lets you "adapt an existing view or Explore without editing the LookML file that contains it". extends, by contrast, produces a new copy.
• Cube. With extends, "cubes of some tenants are enriched with custom measures, dimensions, or joins" while the shared cube stays as it is.
• Malloy. A source is the "primary unit of reusability"; extend adds measures and filters without changing the original.

Let tenants manage their own extensions, whether private to one tenant or shared by several. Routing every customer change through the provider makes the service too expensive to run (SIGMOD, 2009).

Decide which parts of the shared model customers may change. Microsoft's architecture guidance for multi-tenant solutions says "avoid deploying features or a configuration that only applies to a single tenant", and suggests feature flags for temporary differences. Applied to metrics, we recommend this rule: a customer can add a measure of their own, but a customer-specific version of a shared metric belongs behind a declared, named extension, not in a one-off copy.

Enforce Tenant Isolation Separately From the Definitions

A shared definition decides how a number is calculated. It does not decide whose rows it runs on, and the two controls fail separately. Cube places tenant row filters in query_rewrite, which it describes as "a security hook to check your query just before it gets processed". Looker's documentation for access filters warns: "Please do not forget to add access_filter to every Explore that needs it." An Explore without one is unfiltered. AI query agents given approved metric definitions without an access policy still exposed restricted data in a synthetic benchmark (2026 preprint). How the tenant boundary is enforced across the whole request is covered in multi-tenant analytics architecture and row-level security.

Version Metric Definitions Like an API

Treat a dashboard built on a metric like code that calls an API. Google's API design guidance gives the rule for what may change underneath such code: APIs "must not change visible behavior or semantics in ways that are likely to break reasonable user code", and even "changing the default value is considered breaking". A new formula for "active customer" changes semantics in that sense, even though nothing was renamed.

The default policy we recommend for a semantic layer:

Data modeling tools provide controls for these breaking changes:

• New version for breaking changes. dbt's guidance for removing, renaming or retyping a column is direct: "you should create a new model version", and "offer a migration window off the 'old' version", during which consumers can still call the old version by number.
• Deprecation that warns. When a project references a model past its deprecation_date, "a warning is generated"; teams can turn that warning into an error.
• Automatic detection. With model contracts, "dbt will look for breaking changes that could impact downstream consumers" by comparing against the previous project state.
• Recompile on version change. In Cube, the string returned by schema_version tells Cube "the data model should be recompiled", which is how definitions loaded from an external source are versioned.

Across ten open-source database applications and more than 160,000 revisions, "80% of the schema changes happened in 20-30% of the tables", and schema changes forced significant changes in the code that used them. Put versioning effort first on the metrics that change often and that many dashboards use.

Roll a Definition Change Out Tenant by Tenant

Stripe automatically pins each account to the latest available API version when the user makes their first request. The account moves to a new version when it chooses to, and Stripe uses version change modules to keep older API versions out of core code paths.

To roll out a metric definition, use the expand, migrate and contract sequence that Danilo Sato describes as parallel change on Martin Fowler's site:

1. Expand. Publish the new definition next to the old one, under a new version, and pin existing dashboards to the version they were built on.
2. Migrate. Move tenants across one at a time, after checking the numbers on their dashboards under both versions. Microsoft's guidance is to "allow customers to temporarily but not permanently opt out".
3. Contract. Set a deprecation date on the old version, warn on anything still using it, then remove it.

The same Microsoft page adds a requirement for all three steps: "You need to know which version of infrastructure, software, or feature each tenant uses." For metrics, that means a record of which definition version each tenant's dashboards resolve to.

A Checklist Before You Ship a Semantic Layer to Customers

1. Every customer-facing metric has one definition and a named owner.
2. Tenants extend definitions; they do not copy them. Customer-specific measures live in declared extensions that inherit the shared parent.
3. The tenant row filter is applied on every entry point, including exports, scheduled reports and AI questions, and is tested separately from the definitions.
4. Breaking changes are defined in writing: formula, default filter, time grain, type, removal and rename.
5. A breaking change ships as a new version with a migration window and a deprecation date.
6. Each tenant's version is recorded, so you can answer which customers still use the old definition.
7. Rollout goes tenant by tenant, with a before-and-after comparison of the numbers on that tenant's dashboards.
8. The layer's changes are checked automatically against the previous state before release.

If you are comparing vendors instead of building, the same list becomes your questions, together with what each vendor puts in writing about its own versioning policy.

Where Sumboard Stands

Sumboard already lets you set locale, timezone and language on the Organization, the Dashboard and for each Tenant at runtime, and keeps no copy of your data beyond cached results. A semantic model shared by typed and clicked questions is in progress.

If you are evaluating an embedded analytics platform, use the checklist above as your list of questions.

Where to go next

• Architecture articles
• Semantic layer
• Multi-tenant analytics architecture
• Natural language query