What is a semantic layer?

In depth

A semantic layer sits between your storage systems and your reporting tools. It models entities, relationships, metrics, and dimensions using names the business understands. Instead of exposing table columns like "invoice_total" or "cust_id", it publishes "Revenue", "Customer", and "Invoice Date" with calculation rules and filters built in.

A semantic model typically includes:

• Entities and relationships: For example, customers, orders, and products, with defined joins and keys.
• Metrics and calculations: For example, "Revenue", "MRR", and "Active Users", with formulas and aggregation rules.
• Dimensions: For example, time, region, product, or plan.
• Constraints and policies: For example, access control, metric certification, and default filters.

This layer separates business logic from physical tables. You can change a source or add a new table without breaking downstream dashboards, because people depend on named metrics rather than hidden SQL.

Pro tip

Name metrics for decisions, not for tables. For example, "New MRR" is a better name than "fact_subscriptions.amount_sum." Add a short description and an owner so people know who to ask and can trust the number.

Why semantic layers matter

A well-run semantic layer helps leaders make faster, better-informed decisions because everyone works from the same answer.

• Shared meaning: Teams use the same certified definitions for "Revenue", "Net MRR Churn Rate", and "ARPU".
• Centralized organization: Logic lives in one place instead of being scattered across spreadsheets and dashboards.
• Governance with flexibility: Definitions are controlled by a few owners, so business users can explore on their own without redefining numbers.
• Change management: Upstream changes are versioned and communicated, so reports stay current and meetings don't stall over conflicting figures.

How to build a semantic layer

1. Pick your top 10 questions. Define the metrics that will answer them, such as "MRR", "Active Users (28-day)", and "Lead-to-SQL Rate".
2. Write metric statements. Include name, description, formula, grain, filters, and source lineage.
3. Model joins. Declare keys and one-to-many rules to prevent double counting.
4. Encode default logic. Set canonical time grains, time window definitions, and currency formats.
5. Set access rules. Limit access to sensitive information and publish certified versions for company-wide use.
6. Version and test. Stage changes, run sample queries, and investigate unexpected shifts in values.

What to consider before you start

• Ownership: Each metric needs one named owner who approves changes. Without one, definitions drift back into spreadsheets.
• Scope: Start with the metrics your leadership team reviews most. A small, trusted set beats a large, disputed one.
• Maintenance: Definitions change as the business does. Schedule a regular review so the layer reflects how you operate today.

Before you build, write down the five numbers your team argues about most. Agree on one definition for each, and you have the core of your semantic layer.