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.
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.
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.
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.