Ontology vs Semantic Layer: What Each One Actually Is
Skip to content<br>Contents May 22, 2026 · 10 min read<br>Ontology vs Semantic Layer: What Each One Actually Is<br>🌳 High Hanging Fruit<br>Share:
The words ontology and semantic layer have been moving in and out of data team vocabulary for a decade, and they have started showing up in the same sentences as if they were interchangeable. They are not. One describes what your business means by the words it uses. The other is a piece of software that sits between your warehouse and your dashboards. You can have one without the other — and most organizations do — but the cost of confusing them is a stack that looks coherent and isn’t.
This article separates the two, shows where they overlap, and explains why a healthy data practice eventually needs both.
What an Ontology Is
An ontology is a formal model of the concepts in a domain, the relationships between those concepts, and the rules that constrain them. It answers questions like: What is a customer? What counts as an active subscription? Which entities can own a contract? When is a transaction considered closed?
An ontology lives above any particular database. It is a definitional artifact, written in language and diagrams (sometimes in OWL or RDF, often in plain prose backed by an ER diagram). It tells you that a Customer is a party that has placed at least one paid order, that a Customer is either an Individual or an Organization, and that every Order belongs to exactly one Customer. Those statements are true regardless of how your warehouse is structured today.
A good ontology has three properties:
Concepts are named and defined. “Active user” is not assumed to be self-explanatory — it has a written definition with edge cases.
Relationships are explicit. You know which entities can be related and how (one-to-many, many-to-many, optional, mandatory).
Rules are stated. “A subscription cannot be active and cancelled at the same time” is a rule the model enforces, not a coincidence the data happens to obey.
Ontologies belong to the business as much as to the data team. The CFO has opinions about what a customer is. The product team has opinions about what an active user is. An ontology is where those opinions get written down, reconciled, and made the source of truth.
What a Semantic Layer Is
A semantic layer is a piece of software in your data stack. It sits between physical tables (in Snowflake, BigQuery, Databricks, DuckDB) and the consumers of those tables (BI tools, notebooks, AI agents, embedded analytics). Its job is to translate raw warehouse columns into business concepts on demand, so every consumer that asks for monthly_recurring_revenue gets the same number computed the same way.
Concretely, a semantic layer is configuration: SQL snippets, join definitions, dimension and metric declarations, often expressed in YAML or a DSL. Tools in this space include the dbt Semantic Layer / MetricFlow, Cube, AtScale, Looker (LookML), and the metrics layers shipped by warehouses themselves.
A semantic layer typically encodes:
Metrics — a single, version-controlled definition of revenue, active_users, churn_rate, etc., expressed as aggregations over warehouse tables.
Dimensions — the slicing axes (region, plan, channel, signup_cohort) that metrics can be grouped by.
Joins — the canonical relationships between tables, so a consumer can ask for “revenue by region” without re-deriving the join every time.
Access rules — which roles can see which dimensions or metrics.
It is, in effect, a thin layer of business meaning encoded in code that lives inside your data infrastructure.
Where the Confusion Starts
The two concepts get conflated because a semantic layer ends up expressing parts of an ontology — usually the parts that are quantitative. A metric definition in MetricFlow says what revenue is, computationally. An ontology definition of revenue says what the business means by the word and under which conditions a payment counts. The semantic layer’s definition is one possible implementation of the ontology’s definition.
The confusion is reasonable, but it papers over three differences that matter in practice.
1. Scope
An ontology covers concepts that are not necessarily quantitative or even queryable. What is a contract? What are the allowed states of an order? What does it mean for a customer to be “at risk”? These can have implications for metrics, but the ontology itself is broader — it is the model of the domain, not the model of the dashboards.
A semantic layer scopes itself to what can be asked and answered against the warehouse. It is fundamentally a query-time abstraction.
2. Coupling to technology
An ontology is, by design, technology-independent. The same ontology should be valid whether your warehouse is Snowflake today and Databricks tomorrow. It does not assume the existence of a particular table or column.
A semantic layer is tightly coupled to a specific warehouse, a...