Unified Metadata Layer for Power BI and Tableau in Hybrid Cloud

Intergalactic Data Labs
โ
โ
14 min read
Updated October 2026
A unified metadata layer for Power BI and Tableau defines each metric once and serves it to both tools. It pairs a semantic layer, which executes metric logic, with a catalog, which tracks lineage and ownership. In hybrid cloud you also need gateways that reach on premises data. Today the dbt Semantic Layer, AtScale, Cube, and Databricks metric views can feed both tools.
Approach | Power BI path | Tableau path | Hybrid fit | Main limit |
|---|---|---|---|---|
dbt Semantic Layer | Connector in preview | Live connector | Gateway for Service | No Tableau extracts |
AtScale | Live connection | Generated TDS files | Runs on premises or cloud | Commercial license |
Cube | DAX API | SQL API | Cloud or self hosted core | DAX API on Enterprise plan |
Databricks metric views | Query from Power BI | Query from Tableau | Data in Databricks | Unity Catalog only |
Catalog only (Purview, OpenMetadata) | Scans lineage | Scans metadata | Scanner needs network reach | Does not run metrics |
Each tool on its own | Semantic models | Published data sources | Gateway and Bridge | Definitions drift |
Each row is sourced in the sections below. For a wider comparison of semantic layer products, see our guide to semantic layer tools for real time analytics.
What is a unified metadata layer for Power BI and Tableau?
It is one place that holds business meaning for both BI tools, so a metric means the same thing in either. It does two jobs. The semantic part stores metric logic, joins, and dimensions and runs queries. The metadata part stores descriptions, owners, certification status, and lineage.
The two jobs are often bought separately. A semantic layer such as dbt, AtScale, or Cube answers the question "what is revenue". A catalog such as Tableau Catalog, Microsoft Purview, or OpenMetadata answers "where did this number come from". Our explainer on data catalog vs metadata layer vs semantic layer covers the boundary in detail.
Why do Power BI and Tableau numbers drift apart?
They drift because each tool stores its own copy of the business logic. Power BI keeps measures in DAX inside semantic models. Tableau keeps logic in calculated fields, published data sources, and now Tableau Semantics. Two analysts can encode "monthly recurring revenue" with different trial or proration rules, and both versions look correct.
Each tool also certifies only its own content. Power BI lets admins name a small group of reviewers who mark semantic models and reports as certified (Microsoft Learn). Tableau Catalog lets stewards certify data sources and add quality warnings (Tableau Help). A metric can be certified in both tools and still disagree.
The vendors are also building deeper native semantics, which raises the cost of switching later. Microsoft Fabric IQ can generate an ontology from an existing Power BI semantic model and carry DAX measures over as metrics (Microsoft Learn). Tableau describes Tableau Semantics as an AI assisted semantic layer integrated with Salesforce Data 360 (Tableau).
What does hybrid cloud add to the problem?
Hybrid cloud adds network boundaries between the BI service, the semantic layer, and the data. Every live query and every metadata scan has to cross them. That shapes which tools you can use and where you install connectors.
Power BI reaches private sources through the on premises data gateway, which needs only outbound ports (Microsoft Learn). A gateway cluster supports up to 1,000 data sources, and DirectQuery responses are capped at 16 MB uncompressed. Microsoft supports only the last six gateway releases, so someone must own upgrades.
Tableau Cloud uses Tableau Bridge, client software that runs inside your network (Tableau Help). Bridge handles live queries and scheduled extract refreshes for private data over an outbound encrypted connection. If your semantic layer runs on premises, Bridge and the gateway are the paths both tools use to reach it.
Metadata scanning has the same constraint. Microsoft Purview cannot scan a Tableau server that blocks public network access (Microsoft Learn). For hybrid estates, check where each scanner runs before you pick a catalog.
Which architecture patterns work for Power BI and Tableau together?
Four patterns show up in practice. Most teams combine one semantic pattern with one catalog pattern.
Pattern 1, a headless semantic layer between the warehouse and both tools
A standalone semantic layer owns the metrics, and both tools query it live. This gives the strongest consistency because neither tool redefines the logic. The tradeoff is that analysts give up some modeling freedom inside each tool, and you run one more service.
Pattern 2, metrics defined in the lakehouse or warehouse
Databricks metric views define a metric once in Unity Catalog, and Power BI, Tableau, and Sigma can query them (Databricks docs). This works well when most governed data already sits in one platform. It helps less when key data stays in on premises databases outside that platform.
Snowflake semantic views take a related route. Semantic View Autopilot can build a semantic view from an uploaded Tableau or Power BI file (Snowflake docs). The overview documents SQL, Cortex Agents, and Cortex Analyst as query paths, so confirm BI tool support for your version before relying on it.
Pattern 3, a catalog that syncs metadata but not metric logic
A catalog scans both tools and shows lineage, owners, and glossary terms in one place. It improves trust and impact analysis without changing how reports run. It does not stop two tools from computing a metric differently, so it is a complement to Pattern 1 or 2, not a replacement.
Pattern 4, one vendor's native semantics as the hub
Some teams standardize on Fabric IQ or Tableau Semantics and treat the other tool as secondary. This is simplest when one tool already dominates. In Fabric IQ, Ontology and Graph are still in preview (Microsoft Learn), and both options tie your definitions to one vendor's platform.
How do Power BI and Tableau connect to a shared semantic layer?
Each semantic layer reaches the two tools differently, and the limits matter more than the logos. Test your hardest metrics, such as distinct counts and fiscal calendars, in both tools before you commit.
dbt Semantic Layer
dbt lists native integrations for both Power BI and Tableau, plus JDBC, GraphQL, and a Python SDK for other clients (dbt docs). The metric engine, MetricFlow, is Apache 2.0 (dbt Labs). That gives you definitions in readable YAML that live in Git.
The Power BI connector is in preview and requires DirectQuery (dbt docs). Published reports need the connector installed on an on premises data gateway. Custom granularities such as fiscal year are not available, and custom DAX is unsupported. The Tableau connector works on Desktop, Server, and Cloud but supports live connections only, with calculated fields limited to parameter use (dbt docs).
AtScale
AtScale has offered a live connection for Power BI since 2021, processing DAX natively rather than translating it to SQL (AtScale). For Tableau, it generates a TDS file for each published model and uses a PostgreSQL JDBC driver (AtScale docs). It deploys on Kubernetes in public cloud, private cloud, or hybrid setups, and models are written in open source SML (AtScale). The limit is cost, since the platform is commercial.
Cube
Cube's DAX API gives Power BI a native experience with better feature support than its SQL API, through an XMLA endpoint URL (Cube docs). Tableau connects through the SQL API using the PostgreSQL connector, and Cube Cloud can sync the data model to Tableau (Cube docs).
The limit is access. The DAX API is available on the Enterprise plan and is enabled in Cube Cloud, so self hosted Cube Core teams need another path for Power BI.
How do you keep lineage and glossary terms in sync across both tools?
Use each tool's own metadata API, then gather the results in one catalog. Neither BI vendor's catalog fully covers the other tool, so a neutral catalog is often the cleanest home for cross tool lineage. Our guide to enterprise metadata management architecture covers how to design that hub.
Catalog | Power BI coverage | Tableau coverage | Strength | Limit |
|---|---|---|---|---|
Tableau Catalog | None | Lineage and quality warnings | Impact analysis in Tableau | Data Management add-on |
Microsoft Purview | Lineage and live view | Metadata scan in preview | Fits Microsoft estates | No Tableau lineage |
OpenMetadata | Column lineage from DAX | Lineage via Metadata API | Apache 2.0 | No Power BI usage or tags |
Tableau Catalog provides lineage, impact analysis, a data dictionary, and certification, and it sits in the Data Management add-on (Tableau Help). The Tableau Metadata API does not need Data Management, so you can still export Tableau lineage elsewhere. On Tableau Server, an admin must first enable metadata services.
Microsoft Purview lists lineage and live view for Power BI but no lineage for Tableau (Microsoft Learn). Its Tableau scanner is in preview and supports Tableau Server 8.x through 2023.x, without incremental scans (Microsoft Learn). It suits teams that are mostly Microsoft and want Tableau assets visible in the same search.
OpenMetadata is Apache 2.0 (GitHub). Its Power BI connector parses DAX and mashup expressions to build column lineage, but tags and usage are not supported (OpenMetadata docs). Its Tableau connector needs the Metadata API, and source tables are skipped silently if the account lacks Catalog permissions (OpenMetadata docs).
For Power BI, the XMLA endpoint lets tools such as Tabular Editor and DAX Studio read model metadata (Microsoft Learn). It requires Premium capacity or Premium Per User. Read only access is on by default, and read write must be enabled by an admin.
How do you choose the right approach?
Start from where your data lives and which tool your executives trust. The table below maps common situations to a starting pattern.
Situation | Starting pattern | Why |
|---|---|---|
Most data in Databricks | Metric views | Both tools query it |
dbt already runs your models | dbt Semantic Layer | Metrics stay in Git |
Heavy Power BI, large on premises estate | AtScale | Native DAX, hybrid deploy |
Microsoft first, Tableau secondary | Power BI models plus Purview | One vendor to manage |
Need lineage now, metrics later | OpenMetadata | Open source, both tools |
Cost also differs by tool. Power BI Pro is 14 dollars and Premium Per User is 24 dollars per user per month since April 2025 (Microsoft Fabric community). Tableau Standard starts at 15 dollars per user per month on an annual contract (Tableau pricing). Our ranking of business intelligence platforms compares the wider field.
What is a practical rollout plan?
Roll out in small steps, starting with the metrics people argue about. A big bang migration of every report rarely survives the first quarter close.
Step 1, inventory what each tool defines today
Pull measures from Power BI semantic models through the XMLA endpoint, and pull calculations and data sources from the Tableau Metadata API. List every metric that appears in both tools. Mark the ones where totals disagree.
Step 2, pick ten to twenty contested metrics and name owners
Each metric needs one business owner who approves changes. Write the definition in plain language before writing any code. Include grain, filters, time handling, and currency rules.
Step 3, define the metrics once and connect both tools live
Encode the definitions in the shared layer and connect each tool with a live connection. Validate results against the existing reports for at least one full reporting period. Our semantic layer architecture checklist lists the tests worth running.
Step 4, certify, then retire the duplicates
Certify the new sources in Power BI and Tableau so users find them first. Retire the old measures and calculated fields only after owners sign off. Keep lineage in the catalog so the next schema change shows its impact before it ships.
Why should the definitions live in an open format you own?
Your metric definitions are institutional knowledge, and they outlast any one BI contract. If they live only in DAX or only in Tableau Semantics, switching or adding a tool means rewriting them. Keeping them in open formats on infrastructure you control makes them portable.
Standards are moving in that direction. The Open Semantic Interchange project became Apache Ossie in July 2026, an open YAML format for metrics, dimensions, and relationships (Apache Ossie). Snowflake, Salesforce, dbt Labs, and Databricks are named participants, but Microsoft is not. dbt says its Power BI connector's production readiness depends on Microsoft joining (dbt docs).
Shared definitions also matter for AI. An April 2026 study found that explicit business semantics raised text to SQL accuracy by 17 to 23 points across several frontier models (arXiv). The same definitions that align Power BI and Tableau can ground agents that query your data.
Galaxy works with teams to build this semantic foundation on the stack they already run, using internal tooling for semantic layers, ontologies, and entity resolution. It builds in the open, starting with Filament by Galaxy, its Apache 2.0 data movement engine.
Frequently asked questions
What is a unified metadata layer for Power BI and Tableau?
It is a shared layer that holds metric logic, business definitions, ownership, and lineage once, and serves them to both Power BI and Tableau. In practice it combines two parts. A semantic layer executes the metric definitions, and a catalog tracks where data comes from and who owns it. Neither BI tool provides both parts for the other.
Why do Power BI and Tableau show different numbers for the same metric?
Each tool stores its own business logic. Power BI keeps measures in DAX inside semantic models, and Tableau keeps calculations in published data sources and workbooks. When two analysts encode the same metric separately, small differences in filters, time handling, or joins produce different totals. Certification inside each tool does not reconcile them, because each tool certifies only its own content.
Can one semantic layer serve both Power BI and Tableau?
Yes. The dbt Semantic Layer, AtScale, and Cube all document connections for both tools, and Databricks metric views can be queried from Power BI and Tableau. Each has limits. The dbt Power BI connector is in preview and needs DirectQuery, and the dbt Tableau connector does not support extracts. Test your hardest metrics on both tools before you commit.
Do I need a gateway for a semantic layer in a hybrid setup?
Usually yes when data or connectors sit inside your network. Power BI uses the on premises data gateway to reach private sources, and the dbt Semantic Layer Power BI connector must be installed on that gateway for published reports. Tableau Cloud uses Tableau Bridge for live queries and extract refreshes against private network data. Plan gateway capacity and ownership early.
Can Microsoft Purview govern both Power BI and Tableau?
Partly. Purview Data Map lists lineage and live view for Power BI. Its Tableau scanner is in preview, supports Tableau Server 8.x through 2023.x, and Purview lists no lineage for Tableau. Scanning also fails if the Tableau server is not reachable from a public network. Microsoft heavy teams often pair Purview with Tableau Catalog for the Tableau side.
Is there an open source catalog that covers Power BI and Tableau?
Yes. OpenMetadata is Apache 2.0 and has connectors for both tools. Its Power BI connector maps dashboards, reports, and datasets and parses DAX and mashup expressions for column lineage, though tags and usage are not supported. Its Tableau connector ingests workbooks, data sources, owners, tags, and usage, but lineage needs the Tableau Metadata API and Catalog permissions.
Does Tableau Catalog cost extra?
Yes. Tableau Catalog is part of the Data Management add-on rather than a base edition. It adds lineage, impact analysis, a data dictionary, data quality warnings, and certification. The Tableau Metadata API, which lets you query published content metadata programmatically, does not require Data Management, so teams can still extract lineage into another catalog without the add-on.
What license do I need for the Power BI XMLA endpoint?
The XMLA endpoint works on Power BI Premium capacities and Premium Per User, and read only access is on by default. Read write access must be enabled by an admin and allows deployment, scripting, and refresh. Premium Per User costs 24 dollars per user per month, compared with 14 dollars for Pro, so factor that into any plan that depends on XMLA.
What is Apache Ossie and does it help Power BI and Tableau?
Apache Ossie is the new name for the Open Semantic Interchange project, now incubating at Apache. It defines a vendor neutral YAML format for metrics, dimensions, and relationships. Snowflake, Salesforce, dbt Labs, and Databricks are named participants, but Microsoft is not named. dbt says production readiness of its Power BI connector depends on Microsoft joining the standard.
How should a team start unifying Power BI and Tableau metrics?
Inventory the measures in Power BI semantic models and the calculations in Tableau data sources, then list the metrics that disagree. Define the ten to twenty most contested ones once in a shared layer, connect both tools live, and certify the new sources in each tool. Retire the duplicates only after finance and the metric owners sign off.
More articles
Questions
Answered
FAQ
What does Galaxy do?
What is Filament?
What is enterprise context management?
What does working with Galaxy look like?
How do you handle security and compliance?
Why does Galaxy build in the open?
Company
Copyright ยฉ 2026 Galaxy. All rights reserved.