{"slug": "the-who-what-and-why-of-semantic-layers-the-layer-that-decides-whether-your-can", "title": "The Who, What, and Why of Semantic Layers: The Layer That Decides Whether Your Numbers Can Be Trusted", "summary": "A developer argues that semantic layers have become critical for data trustworthiness, especially with the rise of AI agents querying data. The layer translates physical data tables into governed, executable definitions for metrics, dimensions, and entities, improving LLM accuracy on data questions from roughly 40% to over 83%. The post surveys the semantic layer market including dbt, Cube, AtScale, Looker, Snowflake, Databricks, and Dremio.", "body_md": "There is a survey statistic making the rounds this year that I cannot stop quoting: 84 percent of data teams report regularly encountering conflicting versions of the same metric. Not occasionally. Regularly. As in, most reporting cycles include an argument about whether revenue means gross or net, whether churn counts seats or accounts, whether this week's number can be compared to last week's at all.\n\nFor thirty years, the industry's answer to that problem has carried one name: the semantic layer. And for most of those thirty years, semantic layers were a somewhat sleepy corner of the stack, the thing inside your BI tool that a few modelers maintained and everyone else ignored. That era ended abruptly. The rise of AI agents querying data on behalf of humans turned the semantic layer from a nice-to-have into the deciding factor between agents that produce trustworthy answers and agents that produce confident guesses. One frequently cited finding puts the stakes in a single pair of numbers: large language model accuracy on data questions jumps from roughly 40 percent to over 83 percent when the model is grounded in a governed semantic layer rather than raw tables.\n\nSo this article is the full treatment: the who, the what, and the why of semantic layers in 2026. What a semantic layer actually is, in plain language. Why every serious data platform now ships or integrates one. Who builds them, who owns them, and who consumes them, with an honest tour across the whole market, dbt, Cube, AtScale, Looker, the warehouse-native layers from Snowflake and Databricks, and yes, Dremio's approach, where I work and where I will declare my colors before praising anything. By the end, you should be able to explain the category to your CFO, evaluate the tools like a practitioner, and understand why I keep saying this layer is where the AI era gets won or lost.\n\nStrip the jargon and a semantic layer is a translation layer. On one side sits your physical data: tables with names like `fct_orders_v3`\n\nand columns like `amt_usd_net`\n\n, spread across schemas, warehouses, and lakehouses, shaped by years of engineering decisions that made sense at the time. On the other side sit human questions: what was revenue last quarter, how is churn trending, which region is growing. The semantic layer is the formal, machine-readable bridge between the two.\n\nConcretely, a semantic layer contains a few kinds of definitions. Metrics: the named numbers the business runs on, each with its exact calculation, filters, and exclusions. Revenue is the sum of this column, from these tables, excluding refunds and internal test accounts, recognized on this date logic. Dimensions: the ways you slice metrics, time at various grains, geography, product, segment. Entities and relationships: the declaration that a customer is a thing with a key, that orders belong to customers, that the billing system's account identifier and the product database's user identifier refer to the same person. And around those definitions, the operational machinery: access rules about who may see what, caching and acceleration so governed queries come back fast, and interfaces, SQL, REST, and increasingly MCP, through which tools and agents consume it all.\n\nThe defining property, the one that separates a semantic layer from documentation, is that the definitions are executable. When an analyst, a dashboard, or an AI agent asks for monthly recurring revenue by region, the semantic layer generates the correct SQL against the physical tables and returns the governed answer. Nobody re-derives the logic. Nobody copies a formula from a wiki into a query and fat-fingers the exclusion clause. The definition is written once, by someone accountable for it, and every consumer executes the same truth.\n\nThe analogy I use on stage: a semantic layer is the difference between giving someone a warehouse full of unlabeled parts and giving them a catalog with part numbers, descriptions, and an ordering desk. The parts were always there. The catalog is what makes them usable by people who did not build the warehouse. And in 2026, the people who did not build the warehouse include a fast-growing population of AI agents, which is exactly why the catalog suddenly matters so much.\n\nBecause the category gets described in abstractions, let me trace one query through the machinery, since the internals explain most of the differences between tools.\n\nA consumer, a dashboard, a notebook, or an agent, asks for monthly recurring revenue by region for the last six quarters. In a world without a semantic layer, someone translates that into SQL by hand, choosing tables, joins, filters, and formulas, and every translator chooses slightly differently. With a semantic layer, the request arrives as a semantic query: metric names and dimension names, no tables, no joins.\n\nStep one is resolution. The layer looks up the metric definition, the measure it aggregates, the model it lives in, the filters baked into it, and resolves the requested dimensions against the declared relationships. This is where the encoded knowledge pays off: the layer knows that region lives two joins away through the customer entity, knows which join keys are trustworthy, and knows that the revenue measure excludes internal accounts, because someone accountable wrote all of that down once.\n\nStep two is generation. The layer compiles the resolved request into SQL for the target engine, and this is a genuinely hard compiler problem that separates mature tools from demos. Correct handling of fan-out and chasm traps, the join patterns that silently double-count when done naively, is the classic test. Correct time-grain logic, comparing quarters with incomplete months, fiscal calendars, timezone boundaries, is the other. When practitioners say they trust a semantic layer, they mostly mean they trust its SQL generation on these traps.\n\nStep three is optimization, and here the architectures diverge most. A pure pass-through layer sends the generated SQL to the warehouse and inherits its speed and its bill. An acceleration-first layer checks whether a pre-computed structure can answer instead: Cube consults its pre-aggregations, AtScale its aggregate tables, and Dremio its Reflections, transparently rewriting the query against the materialization when one fits. The consumer never knows. The dashboard just comes back in half a second instead of forty, and the warehouse bill shrinks because the expensive scan ran once at materialization time instead of once per viewer. The economics of this step are why I insist acceleration is an adoption feature: interactive speed is what keeps consumers inside the governed path.\n\nStep four is enforcement. The layer applies access rules before results leave: row-level filters by the requester's role, column masking, dimension restrictions. Because every consumer came through the same door, the enforcement is uniform, which is the property that makes auditors relax.\n\nNow you can read any vendor's architecture page fluently. Warehouse-native layers collapse steps two through four into the database itself. BI-native layers run the pipeline inside one tool. Headless layers run it as a service for all tools. Lakehouse-native layers like Dremio's run it inside the engine that already federates the sources. Same four steps everywhere. The differences are where they run and who can consume the result.\n\nThe case for semantic layers has been stable for decades, and then it gained a new clause. Let me make all five arguments, because teams that adopt for only one of them under-invest.\n\n**Consistency.** The Monday-meeting problem. When metric logic lives in every dashboard, notebook, and spreadsheet separately, definitions drift, and the organization spends its decision-making time arguing about whose number is real. A semantic layer makes the definition singular and shared. This is the founding argument, and it remains the daily one.\n\n**Self-service.** Analysts and business users can only serve themselves if the data is legible. A semantic layer packages the tribal knowledge, which tables join to which, which column is the real revenue column, which filter everyone forgets, into the interface itself, so a question does not require a ticket to the three people who remember how the schema works. Every successful self-service analytics story I have seen had a semantic layer underneath it, whether or not it used the term.\n\n**Governance.** Definitions are policy. Who may see salary data, which regions a partner can query, what counts as personally identifiable information: encoding these once at the semantic layer, rather than per-tool, is the difference between governance you can audit and governance you can hope for. The layer is also where change management lives: metric definitions evolve, and a governed layer gives that evolution versioning, review, and history.\n\n**Performance and cost.** Less appreciated but very real: a semantic layer sees every query in terms of business objects, which makes it the natural place for acceleration. Pre-aggregations, materializations, and caches built against governed definitions serve everyone downstream. Organizations report the effect concretely: one large retailer found 80 percent of queries completing in under one second after putting a modern semantic layer with automated aggregates in place.\n\n**And the fifth: AI accuracy.** Connect a language model to a warehouse without semantics and you are handing it raw tables and hoping it guesses what your business means by an active customer. It will not guess right, and worse, it will not know it guessed. The measured gap, roughly 40 percent accuracy on raw schemas versus 83 percent and up when grounded in a governed semantic layer, is the entire text-to-SQL story in two numbers. The hard part was never generating SQL. It was generating the SQL your business would endorse. That requires the endorsements to exist in machine-readable form, which is precisely what a semantic layer is. This argument arrived around 2023, matured through 2025, and in 2026 it is the reason semantic layers headline platform keynotes instead of hiding in modeling documentation.\n\nSemantic layers did not begin with the modern data stack, and knowing the lineage helps you evaluate the present, because every architectural pattern on today's market is a descendant of one of three eras.\n\nThe first era belongs to business intelligence. BusinessObjects introduced the universe in the early 1990s, a modeling layer that mapped database tables to business objects so report writers never touched raw SQL, and it was genuinely revolutionary. Microsoft's Analysis Services and the OLAP cube generation carried the same idea with pre-computed aggregations for speed. Looker modernized the pattern in the 2010s with LookML, definitions as code inside the BI tool, and Power BI and Tableau built their own semantic models along the same lines. The strength of this era was integration: modeling, governance, and visualization in one product. The weakness became its name: the definitions were trapped inside each BI tool, so a company running three BI tools maintained three semantic layers, and the Monday meeting returned through the side door.\n\nThe second era answered that weakness with independence: the universal, or headless, semantic layer, a standalone service between all your data and all your tools. AtScale carried the OLAP heritage into this shape, virtualizing enterprise models with automated aggregates and speaking MDX and DAX to the Excel and Power BI installed base. Cube grew from the developer side, an open source semantic layer with caching, access control, and APIs, built to serve embedded analytics and applications, and lately agents, through SQL, REST, GraphQL, and MCP interfaces. The metrics-layer moment around 2021 and 2022 belongs to this era too: dbt Labs acquired Transform, and MetricFlow became the dbt Semantic Layer, putting metric definitions in version-controlled YAML next to the transformation models that analytics engineers already owned. The strength of this era is neutrality across consumers. Its historical struggle has been adoption gravity: a separate layer is a separate thing to deploy, learn, and route every tool through, and more than one universal semantic layer initiative has died of organizational friction rather than technical failure.\n\nThe third era arrived in 2024 and 2025 when the warehouses themselves made a countermove: Snowflake shipped Semantic Views and Databricks shipped Metric Views in Unity Catalog, semantic definitions as native database objects, created in SQL, governed by the platform, and consumed by each vendor's AI experiences. The strength is obvious, zero additional infrastructure and deep platform integration. The cost is equally obvious, and the vendors do not hide it: definitions written this way live inside one platform, which is a fine trade for a genuinely single-warehouse shop and a trap for everyone who becomes multi-platform later, which, in my experience, is nearly everyone eventually.\n\nAnalysts now slice the 2026 market into four working categories: pure semantic layers (dbt Semantic Layer, Cube, AtScale), warehouse-native views (Snowflake, Databricks), BI-native models (Looker, Power BI, Tableau, GoodData, MicroStrategy), and an emerging context layer that aggregates semantics from all of the above for AI consumption. The 2025 GigaOm Radar for the category named Microsoft, Cube, and AtScale as leaders, which tells you how genuinely mixed across eras the current leadership is. Hold the three-era lens, though, because it explains the deepest question in every evaluation: where should definitions live, in the BI tool, in an independent layer, in the warehouse, or, as I will argue shortly, in the lakehouse where the data itself is unified.\n\nBefore I make Dremio's case, let me give the rest of the market its due, because the complete picture is the point of this article and every one of these tools is the right answer for someone.\n\n**The dbt Semantic Layer** is the natural extension for the enormous population of teams whose analytics logic already lives in dbt. Metrics defined in YAML sit next to the models they reference, flow through the same Git review and CI that transformations use, and serve BI tools and agents through APIs, including an MCP server for agent access. MetricFlow generates the SQL against a dozen-plus warehouses, which makes the definitions warehouse-portable. The honest limits: the hosted layer runs through dbt's commercial platform rather than dbt Core, there is no built-in acceleration cache, and it is metric-centric rather than a full serving layer, which is why a common pattern is model in dbt, serve through something else.\n\n**Cube** is the developer's semantic layer: an open source core under Apache 2.0 with caching and pre-aggregations built in, multi-interface serving across SQL, REST, GraphQL, and MCP, and a design center in embedded analytics and AI applications rather than dashboards. Its recent engineering pace, materialization improvements and aggressive latency work, earned it outperformer status in the analyst coverage. The trade: it is its own modeling language and its own service to run, and teams standardized on dbt semantics face the two-layers question.\n\n**AtScale** is the enterprise heavyweight, with the deepest OLAP lineage, a visual modeling canvas, automated aggregate management, and the MDX and DAX connectivity that Excel-heavy and Power BI-heavy enterprises actually require. It routinely anchors the largest deployments. The trade is weight: real infrastructure, real procurement, justified when the governance and scale demands are real too.\n\n**The BI-native layers** remain excellent inside their worlds. LookML is still a genuinely good modeling language for Looker-standardized, Google-centric shops, and Power BI's semantic models serve the largest BI user base on earth. The eternal caveat holds: definitions in a BI-native layer serve that BI tool first, and consumers outside it second, if at all.\n\n**The warehouse-native views** from Snowflake and Databricks are the right call when platform commitment is genuine and singular. They are the simplest possible deployment, they power each platform's natural-language experiences directly, and they bill as compute rather than license. Accept the coupling explicitly, as one refreshingly blunt evaluation guide puts it, rather than discovering it later.\n\n**And the context-layer entrants**, tools positioning above the semantic layers to aggregate definitions, glossaries, and lineage from many systems into one AI-consumable surface, are the newest species, responding to the fact that most enterprises now have several partial semantic layers and the fragmentation problem has moved up a level. It is early there, and the instinct is correct.\n\nAcross the whole tour, notice the convergence: every serious tool now ships an MCP surface, every roadmap leads with AI agent consumption, and most of the vendors above have joined the Open Semantic Interchange effort. The market disagrees about where semantics should live and increasingly agrees about how they should travel, which is the healthiest possible shape for the disagreement.\n\nNow the house position, colors declared: I work at Dremio, so weigh accordingly, and here is the argument as I would make it to a skeptical architect.\n\nEvery approach in the tour above shares one assumption: the semantic layer sits somewhere other than where the data is unified, in the BI tool, in a standalone service, or inside one warehouse among your several. Dremio's approach starts from a different premise. The platform is a lakehouse that already unifies access: a federated query engine reaches data where it lives, across Iceberg tables, databases, warehouses, and file systems, through zero-ETL federation rather than copies. If one layer already sees all your data, that layer is the natural home for what your data means. Semantics as a property of the unified access layer, not another silo beside the silos.\n\nMechanically, Dremio's AI Semantic Layer is built from virtual datasets: governed, versioned views that layer business logic over physical sources without materializing copies, organized into the bronze-to-gold refinement patterns data teams already think in. On top of the views sits the context that makes the layer AI-ready: AI-generated wikis, descriptions, and labels that document datasets automatically and keep the documentation attached to the data, a living encyclopedia for the business rather than a wiki that rots in another tab. Performance comes from Reflections, transparently substituted materializations that the platform increasingly creates and manages autonomously by watching query patterns, with acceleration claims up to 100x on the workloads they fit, which answers the historical objection that virtual semantic layers are slow. Governance runs through the stack: the semantic layer's access rules bind every consumer identically because every consumer comes through the same engine, and the catalog underneath is Dremio's Open Catalog, powered by Apache Polaris, the open source catalog Dremio co-created with Snowflake, which brings role-based access control and credential vending to the tables themselves. And the agent path is native: Dremio's MCP Server lets external agents from Claude, LangChain, and the rest query the governed, documented, accelerated semantic layer directly, which is the whole five-argument case, consistency, self-service, governance, performance, AI accuracy, delivered through one door.\n\nThe strategic argument underneath is the one I have made across this entire series: Dremio co-created Apache Arrow, co-created Apache Polaris, and is a core developer of Apache Ossie, the incubating open standard for semantic interchange. The through-line is that every layer of meaning should be open and portable, including this one. A semantic layer whose definitions can leave is a fundamentally different commitment than one whose definitions are hostage, and the Ossie converters merged for Polaris point exactly where this is going: semantics defined in open formats, governed in open catalogs, served to any engine and any agent.\n\nIs Dremio's approach right for everyone? No, and the honest boundary is the same one from the tour: if your world is genuinely one warehouse and one BI tool, a native layer is simpler, and if your semantics culture is dbt-first, the gravitational pull of definitions-next-to-models is real. Dremio's argument is strongest exactly where the modern enterprise actually lives: many sources, many consumers, agents arriving, and no appetite for one more copy of the data or one more silo of meaning.\n\nTools get the headlines, but semantic layers succeed or fail on human questions, and any complete treatment owes you this section.\n\nWho authors the definitions? The center of gravity has moved twice. The BI era gave the job to specialist modelers. The modern-stack era gave it to analytics engineers, the dbt generation, who brought software discipline, version control, review, testing, to business logic. The AI era is adding a third author: the platform itself, with AI-assisted documentation, auto-generated descriptions, and inferred relationships doing the first draft that humans then curate. The healthy pattern across all three: definitions have named owners, changes go through review, and the business stakeholders who argue about the metric in the Monday meeting are in the approval loop, because a semantic layer without business sign-off is just engineering's opinion, formatted nicely.\n\nWho consumes? The population tripled. First, humans through BI, the original audience. Second, applications, embedded analytics and data products consuming through APIs, the audience that made headless layers a category. Third, and fastest-growing, agents, consuming through MCP and semantic APIs, which changes the authoring bar in a subtle way: an agent reads the description field. The metadata that humans skimmed past is now load-bearing, because it is precisely what grounds the model's understanding. Sloppy descriptions used to cost readability. Now they cost accuracy.\n\nAnd who pays, politically? Here is the uncomfortable truth from two decades of semantic layer projects: the universal semantic layer has failed organizationally more often than technically. It fails when it is built as a monument, a two-year galactic model of the whole business, instead of a product that ships the twenty metrics leadership actually argues about and grows from proven value. It fails when ownership is nobody's job. It fails when the layer adds latency or friction and consumers route around it, because a semantic layer that is bypassable will be bypassed, which is why performance features like acceleration and caching are adoption features in disguise. The teams that succeed treat the semantic layer like a product with users, an owner, a roadmap, and a service level, and start embarrassingly small.\n\nOne more why, because it reframes the whole buying decision: for the first time, semantic definitions have a credible path to portability.\n\nEvery tool in this article speaks its own dialect, and until recently, that meant the choice of semantic layer was close to a marriage: your business logic, accumulated over years, written in a format only one vendor could read. The Open Semantic Interchange initiative, launched in 2025 by Snowflake with dbt Labs, Salesforce, and a coalition that now exceeds fifty organizations, exists to end that. Its specification for vendor-neutral metric and dimension definitions went live under the Apache 2.0 license in January 2026, and in June the project entered the Apache Incubator as Apache Ossie, with Snowflake, Dremio, and dbt Labs as core developers and converters already merged for dbt, Polaris, and others. I wrote a full article on Ossie, so here I will just state its meaning for this one: the evaluation criterion \"can my definitions leave\" now has a concrete answer to look for, namely, does this vendor participate in the standard and ship converters. Most of the serious ones now do, which tells you the market has accepted that lock-in at the semantics layer is ending the way it ended for file formats, table formats, and catalogs. Buy accordingly.\n\nSince the graveyard of failed semantic layer initiatives is organizational rather than technical, let me close the practical gap with the playbook I have watched work, stage by stage.\n\nStage one is the contested twenty. Do not model the business. List the metrics that generated arguments in the last quarter's leadership meetings, usually fifteen to twenty-five of them, and run the political process first: for each metric, get finance, product, and the data team to one definition with one named owner. This stage requires no tool at all, and it is where most of the value lives. Teams that skip the politics and go straight to YAML ship a beautifully versioned encoding of unresolved disagreement.\n\nStage two is encode and expose. Put the agreed definitions into your chosen layer, under version control, with the owner in the metadata and the business description written as if an agent will read it, because one will. Wire the two or three consumers that matter most: the executive dashboard, the analyst tool, and, increasingly first rather than last, the MCP endpoint for your pilot agent. Resist wiring everything. Breadth before trust is how layers get bypassed.\n\nStage three is prove and measure. Pick the visible wins: the dashboard that now loads in under a second because acceleration kicked in, the two reports that finally agree, the agent that answers churn questions with the endorsed formula and cites the definition. Publish adoption numbers weekly, queries through the layer versus around it, because bypass rate is the health metric. When bypass happens, treat it as product feedback: the layer was too slow, missing a metric, or harder than the old way, and each has a fix.\n\nStage four is grow by demand. New metrics enter through the same review gate, proposed by the teams that need them, approved by owners, shipped in days not quarters. Documentation stays AI-assisted and human-curated. And the definitions themselves stay portable: as the Ossie converters mature, exporting your layer to the open format becomes both an insurance policy and a test that you have not quietly accumulated dialect lock-in.\n\nThe whole playbook fits in a quarter for the first pass, and its unifying principle is the one this article keeps returning to: a semantic layer is a product with users, and products earn adoption one trustworthy answer at a time.\n\nOne more frame before the worked example, because readers of my agentic standards article will want the layers connected explicitly, and everyone else deserves to see why every semantic layer roadmap now leads with agents.\n\nThe agent world spent the past two years standardizing its plumbing: the Model Context Protocol for reaching tools and data, Agent2Agent for coordination between agents, WebMCP for the browser. What none of those protocols carry is meaning. MCP can connect an agent to your warehouse in an afternoon, and the connection delivers raw schemas: table names, column types, and whatever comments someone wrote in 2021. The protocol succeeded. The answer still depends entirely on what the agent finds on the other side.\n\nThe semantic layer is what it should find. Walk the failure and the fix side by side. Without semantics, the agent asked about churn discovers four candidate tables, infers a formula from column names, and returns a confident number computed with logic nobody endorsed. With a governed semantic layer behind the MCP surface, the same agent discovers a churn metric with an owner, a description, an endorsed formula, and executable semantics. It queries the metric rather than the tables, cites the definition in its answer, and its number matches the CFO's dashboard because both flowed from the same source. The 40-to-83-percent accuracy gap I keep citing is exactly this difference, measured.\n\nThis is why the convergence I noted in the tour is total: dbt ships an MCP server for its Semantic Layer, Cube serves agents through MCP alongside its other APIs, AtScale exposes context-serving endpoints, the warehouse-native layers power their platforms' copilots, and Dremio's MCP Server fronts its AI Semantic Layer. The semantic layer has become the natural termination point of the agent protocol stack, the place where standardized plumbing meets governed meaning.\n\nAnd it is why the open standard matters doubly for agents. An agent ecosystem where every semantic layer speaks a private dialect rebuilds the fragmentation problem one level up: your agents become fluent in one vendor's semantics and illiterate in the rest. Apache Ossie's promise, definitions in a neutral format that any layer can serve and any agent can consume, is the semantic equivalent of what MCP did for tools. The organizations wiring agents to semantics through open interfaces today are building once. The ones wiring to proprietary semantic APIs are building per vendor, and they will feel it at exactly the moment agent adoption makes rewiring expensive.\n\nThe compressed takeaway for architects: in the agent era, your semantic layer is not a BI feature. It is the knowledge interface of your organization, the layer that determines what every AI system believes your business means. Fund it accordingly.\n\nLet me compress everything above into a single concrete story.\n\nA subscription company's leadership fights about churn until the analytics lead does the political work: finance, product, and data agree on one definition, cancellations excluding payment failures that recover within seven days, divided by period-start actives, monthly. Now the technical choices from this article play out.\n\nWritten into a BI-native layer, the definition fixes the dashboards, and only the dashboards. The data science notebooks and the new AI assistant never see it, and drift resumes within a quarter. Written into the dbt Semantic Layer, it lives in reviewed YAML with lineage to the models beneath, and serves any tool that speaks the APIs, a big step, though queries lean on the warehouse and there is no acceleration underneath. Written into a warehouse-native view, the platform's own copilot answers churn questions correctly, and the second warehouse the company acquires next year answers them differently. Written into Dremio's semantic layer, the definition becomes a governed virtual dataset over the federated sources, the wiki documents it where every consumer reads it, a Reflection accelerates it to interactive speed, the same RBAC binds the analyst's dashboard and the agent's MCP query, and, as the Ossie converters mature, the definition itself is exportable in an open format.\n\nEvery path beats the status quo of definitions-in-dashboards. The differences are exactly the who, what, and why of this article: who can consume, what stays fast and governed, and why the definitions remain yours. Choose with all three in view.\n\nThe recurring questions, answered directly.\n\n**Semantic layer, metrics layer, metrics store, headless BI: are these different things?** Mostly marketing vintages of one idea, with a real distinction hiding inside. A metrics layer or metrics store focuses narrowly on metric definitions, the named numbers and their formulas. A full semantic layer adds the surrounding model: dimensions, entities, relationships, access rules, caching, and serving interfaces. Headless BI was the 2021-era term for a semantic layer decoupled from any particular BI tool. In 2026 usage, semantic layer has won as the umbrella term, and the practical question to ask any tool is not what it calls itself but which of those components it actually ships.\n\n**Is a semantic layer the same thing as a data catalog?** No, and they are converging neighbors. A catalog inventories and governs what data exists. A semantic layer defines what the data means and executes those definitions as queries. The border is blurring productively: catalogs like Apache Polaris are growing semantic model support, semantic definitions are increasingly governed as catalog assets, and Dremio's platform treats catalog, semantics, and query as one governed surface. Expect the two categories to keep merging.\n\n**Do I need a semantic layer if I have good dbt models?** Transformations and semantics are different jobs. Clean, tested models give you trustworthy tables. A semantic layer gives you trustworthy answers, metrics with governed logic that any consumer, including agents, can execute without re-deriving. If dbt is your center, the dbt Semantic Layer is the natural first step, and the gap it leaves, serving, caching, non-dbt consumers, is exactly what the rest of the market fills.\n\n**Are semantic layers just for big enterprises?** The Monday meeting happens at twenty-person startups, and the AI accuracy argument applies at every size. What scales down is the implementation: a small team's semantic layer is twenty well-defined metrics under version control, not a platform project. Start there regardless of size.\n\n**Will AI just make semantic layers obsolete by understanding raw schemas?** The evidence runs the other way, and the 40-to-83-percent finding is the cleanest expression of it. Models get better at SQL, and no model can infer which of your four defensible churn formulas is the endorsed one, because that is an organizational fact, not a pattern in the schema. AI raises the value of encoded semantics. What AI does change is authoring: expect the drafting of definitions and documentation to become increasingly AI-assisted, with humans as curators, which is precisely the design of AI-generated wikis and labels.\n\n**Universal semantic layer or per-tool layers?** The honest answer is that most enterprises will run a hybrid for years: a primary governed layer plus native layers at the edges, stitched together by the emerging standards. The practical advice: pick one place as the source of truth for the metrics that matter, demand open interfaces (SQL, REST, MCP) and standard participation (Ossie) from it, and treat everything else as a consumer, not a second author.\n\n**What is the single biggest implementation mistake?** Building the monument. The galactic model of the entire business, two years in the making, obsolete on arrival, bypassed by everyone with a deadline. Ship the twenty contested metrics first, put owners' names on them, measure adoption weekly, and grow from demonstrated trust. Semantic layers are products, and products earn their users.\n\nThe semantic layer spent thirty years as the most important boring idea in analytics: define the business's meaning once, formally, and let every consumer execute the same truth. What changed in this decade is the population of consumers. Humans could route around missing semantics by asking a colleague. Agents cannot, and they arrive by the thousands, which is why the sleepy layer now headlines keynotes, why every warehouse, BI tool, and lakehouse ships one, and why an open standard for the definitions themselves just entered the Apache Incubator.\n\nThe who, what, and why compress to this: the what is executable meaning, the why is trust at machine scale, and the who is, increasingly, everyone, every author from analytics engineer to AI assistant, every consumer from dashboard to agent. The organizations that treat their definitions as a governed, portable, owned asset are building the foundation the next decade runs on. The ones that leave meaning scattered in dashboards are training their future agents to guess.\n\nIf you want to build that foundation properly, from the table formats and catalogs underneath to the semantics and agents on top, that is what my books are for. I co-authored Apache Iceberg: The Definitive Guide and Apache Polaris: The Definitive Guide for O'Reilly, with further titles on lakehouse architecture, data engineering, and agentic analytics.\n\nBrowse the full collection of my books on data and AI at [books.alexmerced.com](https://books.alexmerced.com).", "url": "https://wpnews.pro/news/the-who-what-and-why-of-semantic-layers-the-layer-that-decides-whether-your-can", "canonical_source": "https://dev.to/alexmercedcoder/the-who-what-and-why-of-semantic-layers-the-layer-that-decides-whether-your-numbers-can-be-14b6", "published_at": "2026-07-12 00:04:01+00:00", "updated_at": "2026-07-12 00:13:12.707058+00:00", "lang": "en", "topics": ["artificial-intelligence", "large-language-models", "ai-agents", "ai-infrastructure", "developer-tools"], "entities": ["dbt", "Cube", "AtScale", "Looker", "Snowflake", "Databricks", "Dremio"], "alternates": {"html": "https://wpnews.pro/news/the-who-what-and-why-of-semantic-layers-the-layer-that-decides-whether-your-can", "markdown": "https://wpnews.pro/news/the-who-what-and-why-of-semantic-layers-the-layer-that-decides-whether-your-can.md", "text": "https://wpnews.pro/news/the-who-what-and-why-of-semantic-layers-the-layer-that-decides-whether-your-can.txt", "jsonld": "https://wpnews.pro/news/the-who-what-and-why-of-semantic-layers-the-layer-that-decides-whether-your-can.jsonld"}}