A SQL semantic layer is a governed translation layer that sits between your data warehouse and your BI tools, defining metrics, dimensions, and business logic in one place so every tool, every team, and every AI query returns the same number. If your finance team's revenue figure doesn't match what operations sees in their dashboard, you almost certainly don't have a visualisation problem — you have a semantic layer problem. And it's one of the most expensive, trust-destroying issues we see at growth-stage companies.
In 2026, fixing this is no longer optional. As AI agents, conversational BI, and self-service analytics move from experiment to daily workflow, inconsistent definitions don't just confuse humans — they cause AI systems to produce confidently wrong answers at scale. The companies getting ahead of this aren't the ones with the fanciest dashboards. They're the ones who did the unglamorous work of governing their metric definitions first.
Why Do Business Metrics Show Different Numbers in Different Dashboards?
This is the question we get asked most often, in one form or another. A founder sees £2.1M in MRR in the finance dashboard. Their head of sales sees £2.3M in the CRM-connected report. The head of product sees £1.9M in the product analytics tool. All three numbers are calculated from the same underlying transaction data — so how can they all be different?
The answer is almost always the same: business logic has been defined independently in each tool, by different people, at different points in time, without any governance or documentation linking them together.
<cite index="14-6,14-7,14-8">Definitions drift across tools. "Revenue" in Tableau doesn't match "Revenue" in Power BI, and neither matches what an AI agent returns in Slack or Google Meet. Teams spend hours reconciling numbers that are "almost right" but never aligned.</cite>
A pattern we see repeatedly in our work with early-stage companies: a single metric like "active customers" has been quietly redefined three or four times as the product evolved — once in a Google Sheet, once hardcoded into a Looker explore, once in a BI tool calculated field, and once in a Slack bot someone built during a hackathon. Nobody documented any of it. The metric has four different values depending on where you look, and nobody knows which one is right.
<cite index="9-1">Analysis of 500+ data teams from late 2024 through early 2026 found that 35% of teams still don't use a dedicated semantic layer — they define metrics in BI tools or don't standardise metrics at all.</cite> For growth-stage businesses, that number is likely higher: pre-Series B companies are building fast, and metric governance is rarely the first thing prioritised.
The business cost of this isn't just wasted time in alignment meetings. It's decisions made on bad numbers. A Series A payments company we worked with had been calculating net transaction volume differently in their finance system versus their operational dashboard for over eight months. The gap wasn't visible until we modelled both definitions in SQL and ran them side by side — at which point it became immediately clear which was correct and which had a silent filtering error. The wrong number had been informing a key commercial decision throughout that period.
📺 Watch: The BIG LIE About Semantic Layers in Data Modeling
What Is a SQL Semantic Layer and How Does It Actually Work?
<cite index="16-10,16-11">A semantic layer in data analytics is a business-friendly abstraction between your warehouse or data lake and your BI and AI tools. It maps raw tables and columns into named entities, metrics, relationships, and policies so people and machines can query data using consistent business terms instead of technical schemas.</cite>
In practical terms, this means codifying answers to questions your organisation asks every day:
- What exactly is a "customer"? Is it anyone who has signed up, or only those who have made a purchase in the last 90 days?
- How is "revenue" calculated? Gross or net? Including or excluding refunds? Recognised on booking or on settlement?
- What does "active" mean for a subscription product — logged in once in 30 days, or used a core feature?
<cite index="16-12,16-13,16-14,16-15">A semantic layer is where you codify: what a Customer, Order, Product, Account, or Policy is; how Revenue, Active Users, Churn Rate, or Gross Margin % are calculated; how those entities are joined and at what grain; and which users are allowed to see which rows and columns.</cite>
<cite index="2-2,2-3">The dbt Semantic Layer, powered by MetricFlow, represents the most widely adopted vendor-neutral semantic layer approach in 2026 — positioning this tool squarely at data teams already using dbt for transformation, and treating semantic models as code artefacts subject to the same development practices as data transformations.</cite>
Once those definitions are codified in the semantic layer, every BI tool, every AI query, and every analyst pulling data gets the same answer — because they're all querying the same governed logic, not each writing their own interpretation of it.
<cite index="2-4,2-5">Metrics, dimensions, and entities are defined in YAML files co-located with dbt models, enabling collaborative development through Git workflows, pull request reviews, and continuous integration pipelines. When a metric definition changes, the update goes through version control, enabling auditability and rollback capabilities.</cite>
This is the architectural leap most early-stage companies miss: they treat metric definitions as a BI problem, so they solve it inside the BI tool. That works until you have a second BI tool. Or an AI assistant. Or a new analyst who doesn't know the history. The semantic layer moves that logic upstream — into code, version-controlled, tested, and shared across every downstream consumer.
What Breaks When You Don't Have One: Real Patterns From the Field
In our delivery work, the absence of a semantic layer tends to manifest in one of three ways — and all three are recognisable within the first week of a new client engagement.
The Spreadsheet Escape Hatch. Finance can't trust the dashboard, so they pull raw data and rebuild the metric in Excel. Their number becomes the "real" one. But it's not connected to anything automated, it breaks when someone edits the wrong cell, and it introduces a new definition that nobody else uses. We have rebuilt dozens of these as governed dbt models. The outcome is always the same: the calculation that was taking 30–50 minutes to manually assemble every week now runs automatically, and the number matches across every surface the business uses.
The Metric That Accumulates Versions. Someone asks for "churn rate" and gets three different answers from three different dashboards, each built at a different point in time. Nobody deletes the old dashboards — they just build new ones. Eventually the organisation stops trusting any of them.
The Onboarding Black Hole. A new data analyst joins and spends their first month trying to understand what the existing metrics mean. There is no documentation. They ask around, get inconsistent answers, make their best guess, and build something slightly different again. The problem compounds with every hire.
<cite index="13-4,13-5,13-6">AI didn't introduce new data problems; it exposed the ones organisations had been living with for years. As generative AI moved from proof of concept to production, long-standing issues around definitions, governance, and metric consistency surfaced in ways that couldn't be ignored. The tolerance businesses had for semantic drift — including conflicting definitions, inconsistent metrics, and undocumented logic — ran out the moment AI agents started consuming that data.</cite>
For companies deploying AI assistants or conversational analytics on top of their data, this is now a hard constraint: <cite index="11-13,11-14">benchmarks show LLM accuracy jumps 3–5× when grounded in a semantic layer. Without one, they're not just inaccurate — they're unsafe.</cite>
If you are evaluating where your analytics stack sits today, explore how Fintel Analytics approaches semantic layer design and data modelling — we help growth-stage businesses move their business logic out of spreadsheets and BI tools and into governed, version-controlled dbt models.
How to Build a SQL Semantic Layer: A Decision Framework for Growth-Stage Companies
Not every company needs to implement a full semantic layer from day one. Here is the framework we use when assessing where a client sits and what to do next.
Stage 1 — Pre-semantic layer (the danger zone). Metrics are defined in BI tool calculated fields, spreadsheets, or ad-hoc SQL. No documentation. No version control. Business logic lives in the heads of two or three people. This is where most Series A companies are when we first engage with them.
What to do: Start with an audit. List the ten most-used business metrics and find every place each one is defined. The inconsistencies will be immediately visible. Prioritise the highest-stakes metric (usually revenue or a core operational KPI) and move it into a dbt model first.
Stage 2 — dbt models exist, but no MetricFlow. Transformations are in dbt, data is landing in BigQuery or Redshift, but metrics are still being defined in the BI layer. This is progress, but the problem isn't fully solved — each BI tool still has its own metric logic, and they can still diverge.
What to do: Migrate metric definitions into dbt MetricFlow semantic models. Define measures, dimensions, and entities in YAML. <cite index="6-5,6-6">The dbt Semantic Layer eliminates duplicate coding by allowing data teams to define metrics on top of existing models and automatically handling data joins — powered by MetricFlow, it simplifies the process of defining and using critical business metrics within your dbt project.</cite> If you're also debugging slow-running transformations at this stage, our guide on why your dbt models are running slow covers the most common performance issues we see in production.
Stage 3 — Semantic layer implemented, single BI tool consuming it. MetricFlow definitions are in place, one BI tool (Holistics, Looker, or similar) is consuming them, and you have a tested, governed definition for your core metrics. This is a healthy state for a Series A or early Series B company.
What to do: Document every metric definition in your data catalogue or dbt docs. Assign metric ownership to specific team leads. Add dbt tests to catch definition drift at the model level — if the underlying table structure changes, you want to know before it silently corrupts a metric.
Stage 4 — Multi-tool semantic consistency. Multiple BI tools, AI assistants, embedded analytics, and external APIs all consuming the same governed definitions. <cite index="2-10,2-11,2-12">The emergence of the Open Semantic Interchange (OSI) in 2025 represents a pivotal industry development — competitors including dbt Labs, Snowflake, and Salesforce began collaborating to standardise semantic layer definitions in vendor-neutral YAML format, enabling organisations to define metrics once and have every tool consume those definitions.</cite>
For most growth-stage companies we work with, Stage 3 is the right target: mature enough to have a single source of truth, pragmatic enough to be achievable within weeks rather than months.
What Does Implementing a Semantic Layer Actually Deliver?
The value is concrete and measurable. Here is what we see in practice.
Metric reconciliation time drops to near zero. When every surface queries the same semantic model, the finance-vs-ops reconciliation meeting stops happening. One global fintech we worked with had been running a weekly 90-minute meeting to resolve dashboard discrepancies. After migrating their core metrics into governed dbt models and connecting Holistics BI to the semantic layer, that meeting was cancelled permanently. The dashboards agreed because they were reading from the same definition.
Onboarding accelerates. New analysts arrive to a documented, version-controlled definition of every metric. Instead of spending weeks reverse-engineering what "active users" means, they read the YAML file, check the dbt docs, and start contributing within days.
AI tools become trustworthy. <cite index="7-28,7-29,7-30,7-31">Instead of asking an LLM to write raw SQL, you define a structured ontology — metrics, dimensions, entities, and the relationships between them — that encodes your business logic. The LLM's job is then reduced to decomposing a natural language question into the correct combination of metrics and dimensions. MetricFlow handles the actual query generation deterministically, meaning the LLM cannot produce an incorrect join or a bad aggregation: if it picks the right metric and dimensions, the query is guaranteed to be correct.</cite>
Dashboard delivery time falls. <cite index="6-1">Organisations report 80% of queries completing in under one second after implementation, with dashboard delivery times decreasing significantly.</cite> When analysts don't have to rebuild metric logic from scratch for every new report, the time from question to dashboard drops sharply.
<cite index="1-3,1-4,1-5">A $50M SaaS company spent $400K implementing augmented analytics without establishing data governance first — within six months, adoption dropped to 12% as conflicting metric definitions destroyed user trust. The core problem wasn't the technology, it was prioritising innovation without strategic fit.</cite> The sequence matters: build the semantic foundation before building the AI layer on top of it, not after.
Frequently Asked Questions
Q: What is a SQL semantic layer and why does it matter for my business?
A: A SQL semantic layer is a governed abstraction between your data warehouse and your BI or AI tools. It defines business metrics — revenue, churn, active users — once in code, so every tool returns the same answer. It matters because inconsistent metric definitions are one of the leading causes of decisions being made on bad data at growth-stage companies.
Q: Do I need a semantic layer if I'm only using one BI tool?
A: If you have one BI tool and a small data team, you can often manage without a dedicated semantic layer in the short term. But as soon as you add a second tool, an AI assistant, or a new analyst who doesn't know the history behind your calculated fields, the inconsistency problem emerges. It is almost always cheaper to build the semantic foundation early than to retrofit it after trust has broken down.
Q: How does the dbt Semantic Layer differ from defining metrics in a BI tool?
A: Defining metrics in a BI tool embeds business logic inside a specific vendor's platform. If you add a second tool, you have to redefine the metric manually and keep both definitions in sync. The dbt Semantic Layer defines metrics in version-controlled YAML co-located with your dbt models — any connected tool queries the same definition, so consistency is guaranteed by architecture rather than discipline.
Q: How long does it take to implement a semantic layer for a growth-stage company?
A: For a company with an existing dbt project and a defined set of core metrics, migrating the most critical 10–15 metrics into MetricFlow semantic models typically takes two to four weeks. A full implementation covering all business domains takes longer, but the right approach is to start with the highest-stakes metrics and expand iteratively. You will see the value from week one.
Q: What BI tools work with the dbt Semantic Layer?
A: As of 2026, the dbt Semantic Layer supports integrations with a growing list of tools including Holistics BI, Looker, Tableau, Power BI, Hex, and others via JDBC, GraphQL, and REST APIs. Holistics BI, which Fintel Analytics partners with, offers particularly strong support for dbt-native semantic modelling — making it a natural fit for growth-stage companies building on BigQuery or a similar modern cloud warehouse.
The Metric Inconsistency Problem Is Solvable — But Only If You Fix the Root Cause
If your dashboards show different numbers, your AI tools return unreliable answers, and your teams spend meaningful time every week reconciling figures that should agree automatically, the root cause is almost certainly a missing or broken semantic layer. At Fintel Analytics, we have helped fintech, payments, and e-commerce businesses untangle exactly this problem — auditing broken metric definitions, migrating business logic into governed dbt models, and connecting those models to BI tools that deliver a single, trusted source of truth across the organisation. The fix is architectural, not cosmetic, and it pays for itself faster than almost anything else you can do with your data stack.