Choosing the Right Semantic Layer Architecture

The 5-Minute Guide for a Data Architect: How a Semantic Layer translates complex database logic into reliable, company-wide business concepts.

Imagine you are in an executive meeting. The Head of Marketing says, “We made $1 million in revenue last month.” A minute later, the Head of Finance says, “Actually, revenue was $900,000.” The meeting grinds to a halt. Nobody is looking at actual performance anymore; everyone is arguing over who has the correct number.

The confusion does not happen because someone is bad at math. It happens because Marketing and Finance are using two different definitions of the word “revenue.” Marketing might count every order submitted, while Finance only counts orders that have actually cleared the bank.

To fix this, companies deploy a centralized data dictionary known as a semantic layer architecture. It takes the messy, confusing tables inside a company’s database and translates them into clear, agreed-upon business terms like Revenue, Active Customer, or Churn Rate, so that everyone is playing by the same rules.

Why the semantic layer has become critical for AI

The semantic layer has become one of the most important components of any modern marketing data stack, and AI is the main reason why.

Companies want AI assistants to analyze their data: an executive types, “What was our top-selling product in Europe last quarter?” and gets an instant, accurate answer. But AI is notoriously poor at guessing what raw data means. Point an AI tool at an unorganized database, and it will look at a column named total_amount and blindly add it up, completely unaware that the column includes cancelled orders, taxes, and shipping fees.

Without a semantic layer acting as a context engine, an AI in marketing setup is practically blind. A semantic layer does more than hold the formula for “revenue.” It maps the entire ecosystem of your data: it defines relationships between tables, identifies that user_id in one system matches customer_guid in another, and provides the business context that turns raw fields into meaningful concepts.

Historically, without this centralized model, business rules had to be hardcoded directly into individual dashboards and spreadsheets. If the logic changed, everything broke. The semantic layer sits between your data warehouse and your downstream tools, ensuring that whether a human opens a BI tool or an AI agent generates a SQL query, both use the exact same logic, data model, and context.

Today, companies face a fundamental architectural decision: where should this data dictionary actually live? There are four main options.

Option 1: The semantic layer inside the data warehouse

In this model, you build your semantic layer directly inside the data warehouse where all your data is stored, for example Snowflake or Databricks.

How it works: The same system that holds your data also holds the definitions for your metrics and the context for all your fields. Tools like Snowflake Cortex or Databricks Genie can then query this context natively.

Pros: A single source of truth. Because the definitions live right next to the data, security is tight. Modern cloud data platforms now offer native AI agents and LLM functions, so by housing your semantic layer here, these tools can analyze data with full business context, without the latency or risk of moving data to external AI platforms.

Cons: You are locked into that specific database provider’s ecosystem. If you ever switch platforms or add a second consumption tool, the logic does not travel with you.

Option 2: The semantic layer inside the BI tool

This is the traditional approach. The semantic layer lives inside the specific software people use to build dashboards and reports, such as Power BI or Tableau.

How it works: You connect your BI tool to the raw database, then define your metrics, relationships, hierarchies, and field descriptions natively inside that reporting ecosystem.

Pros: This is the exact foundation required to use tools like Microsoft Copilot or Tableau Pulse effectively. By defining your semantic layer here, you give the native BI AI the precise context it needs to answer natural language questions accurately for business users, directly on top of the reports.

Cons: The definitions are trapped inside that specific tool. A data scientist or AI tool working outside that dashboard software cannot access them, which leads to duplicated work and fractured logic. In practice, this option looks attractive until a second BI tool gets added and the definitions break.

Option 3: The semantic layer as middleware

This is a newer, increasingly popular approach for modern data teams. Instead of putting the dictionary in the database or in the dashboard, you put it in a dedicated, independent layer that sits between the two, using tools like the dbt Semantic Layer powered by MetricFlow.

How it works: It acts as a universal translator sitting centrally in your repository. You define dimensions, entities, and measures in dbt configuration files. When a person or an AI agent asks a question via a connected BI tool or API, MetricFlow dynamically compiles those configurations into optimized SQL, passes it to the database to execute, and returns the answer. For the full technical reference, see the dbt Semantic Layer Documentation.

Pros: Completely tool-agnostic. Whether you are looking at a dashboard, a spreadsheet, or asking an AI assistant a question, everyone is pulling from the exact same master dictionary. Definitions live as code, which means version control, automated testing, and peer-reviewed changes are standard practice. For a deeper look at how dbt works in a real marketing data setup, see our post on Omni and dbt: Clarity and Speed for Your Data Stack.

Cons: It adds another layer to manage and pay for, and it requires a technical data engineering team to set up and maintain.

Option 4: The Open Semantic Interchange (OSI) approach

This is where the industry is heading, but it is not plug-and-play yet. Instead of choosing a specific piece of software to hold your definitions, you rely on an open-source, universal standard that every vendor agrees to speak.

How it works: You define your metrics using an open standard rather than locking them into a single vendor’s database, a specific dashboard, or a standalone tool. Because it is completely open, your cloud warehouse, your BI dashboards, and your AI agents can all read, write, and sync these definitions natively. It decouples the definition of the data from the execution of the data.

Pros: Maximum flexibility and zero vendor lock-in. If you switch database providers or swap your dashboarding tool, you do not lose your data dictionary. It allows the semantic layer to be federated, so different teams can own their own definitions while still connecting to the same central ecosystem.

Cons: Because it relies on open standards and cross-vendor agreement, it is still maturing. It requires your existing data stack to fully support these open protocols, which can lead to integration complexities depending on the tools you use.

Which semantic layer architecture is right for your company?

To make the right choice, look beyond the technology and ask two fundamental questions: who is going to own and maintain this logic, and how close to day-to-day business operations does it need to sit?

Option 1: Go with the data warehouse

Choose this if your company has fully standardized around a single cloud data platform like Snowflake or Databricks and your primary goal is security, centralization, and native AI integration. Day-to-day creation of definitions can be handled by a Data Analyst, while the Data Engineer owns the underlying platform governance and version control.

Option 2: Go with the BI tool

Choose this only if you are a smaller, fast-moving team doing 100% of your reporting inside a single tool like Power BI or Tableau, and your corporate AI strategy centers on BI-native assistants like Microsoft Copilot or Tableau Pulse. From experience with mid-market companies, this option looks attractive at first, until a second BI tool gets added and the definitions break.

Option 3: Go with middleware (our recommendation)

Choose this if you are building a modern, multi-tool marketing data stack. When your data needs to feed multiple dashboards, financial spreadsheets, and autonomous AI agents simultaneously, this independent middle layer is the most robust approach. Definitions are managed as code, which means version control, automated testing, and peer-reviewed changes become standard practice. Business analysts can still contribute to and edit definitions within a governed framework. If your team wants to build hands-on dbt skills, the HMA Academy offers a dedicated Mastering dbt training.

Option 4: Go with the open standard

Choose this if you are an enterprise-level or rapidly growing company building for the next decade. OSI solves the classic tug-of-war between engineers and analysts through federated ownership: data engineers own core foundational definitions, while business analysts own specific operational metrics like Marketing Qualified Lead (MQL), each at the appropriate layer of the architecture.

Conclusion

When evaluating these four architectures, the standalone middleware layer, specifically the dbt Semantic Layer with MetricFlow, is our preferred choice for modern marketing data teams. Locking your business definitions inside a specific dashboard or a specific cloud data warehouse forces your organization’s logic into a single vendor’s ecosystem. If you ever need to introduce a second data consumption tool, a separate AI orchestration platform, or an external data science notebook, you are forced to duplicate your SQL code and risk splitting your single source of truth.

By using the dbt Semantic Layer, your business definitions live as code within your central transformation pipeline. This brings standard software engineering practices, such as version control, automated testing, and deployment pipelines, directly to your metrics dictionary. Whether a data scientist runs a Python script, an executive views a Tableau dashboard, or a generative AI agent runs a natural language query, all three are guaranteed to calculate your KPIs using the same unified logic.

What our customers often want to know.

FAQ on Semantic Layer Architecture