Semantic Models: Data Modelling for the Modern Data Stack
How Semantic Models work and how will they change our work
Lately, I’ve been having conversations with my team that start with questions like “What does company mean in this table?” or “Does this field refer to billing or operational accounts?” These questions aren’t coming from new joiners. They come from three experienced data professionals who know our stack well. And still, we often find ourselves unsure about what some fields actually mean. That made me realise, if we struggle with this as data engineers, it must be even harder for analysts, product teams, or leadership.
We're excited to co-write this post with
from , Head of Data Engineering, who has over 15 years of experience in data and software. We came together to explore what semantic models are, how they are changing the way we model and share data, and what we think their role means for the future of data engineering.Here’s what we’ll cover:
What are semantic models?
How do they differ from traditional data modelling approaches?
Practical use cases, benefits, and trade-offs.
Our perspectives on where data modelling and analytics are heading next.
For more posts like this, don’t forget to subscribe both
and .You may also check Yordan’s free e-book, Master Stakeholder Influence, available here: [link]1
What is a Semantic Model?
A semantic model serves as a conceptual layer that translates raw data structures into business-meaningful concepts and relationships. Unlike physical data models that focus on how data is stored, semantic models focus on what the data means to the business.
A Simple Analogy
Think of a semantic model as a restaurant menu. The kitchen (your data warehouse) contains all the raw ingredients and complex preparation methods. Customers (business users) don't need to know how to dice vegetables or operate an industrial oven, they just want to order a dish by name and understand what they're getting.
The menu (semantic model) presents these kitchen capabilities in a way that makes sense to diners:
Items are organised logically (appetisers, main courses, desserts)
Each dish has a clear name and description
Prices are consistent
Special dietary needs are marked
Ingredients are listed, but preparation details are abstracted away
Just as a menu creates a shared language between kitchen and customers, a semantic model creates a shared language between data engineers and business users.
Real-World Example
Consider an e-commerce company tracking "Customer Lifetime Value." In a traditional approach, this metric might be calculated differently across departments:
Marketing might include only completed orders
Finance might factor in returns and refunds
Product teams might use different time windows
A semantic model would provide a single, authoritative definition that all teams reference, eliminating these inconsistencies.
The Purpose of Semantic Models
Semantic models address several critical needs:
Consistency: Ensuring metrics are defined identically across all analytics tools
Accessibility: Enabling non-technical users to explore data without SQL knowledge
Governance: Managing access controls and data lineage in one place
Reusability: Defining metrics once and using them everywhere
In practice, a semantic model acts as a translation layer between your data warehouse and your business users. It abstracts away the complexity of underlying tables, joins, and transformations, presenting a business-oriented view of data instead.
Traditional Data Modelling vs Semantic Models
In the world of data, how we model information fundamentally shapes how it's used, governed, and understood. While traditional models once dominated the business intelligence landscape, modern tooling and needs have redefined what data modelling means today.
What Do We Mean by Traditional Data Modelling?
Traditional data modelling is grounded in formal architecture and long-term planning. Techniques like Inmon, Kimball, and Data Vault were designed to support large-scale enterprise data systems. These approaches prioritise consistency, reuse, and governance.
Key characteristics:
Star or snowflake schemas with clear fact/dimension separation
Rigid, pre-planned hierarchies
Normalised staging layers
Heavy reliance on ETL pipelines
These models shine in environments where data changes slowly, requirements are stable, and long-term maintenance is prioritised over agility.
What Does Modern Data Modelling Look Like?
Modern data modelling, particularly within the modern data stack, is built for flexibility and speed. Instead of enforcing tight schemas, it prioritises business logic and accessibility, often using tools like dbt or SQLMesh. In practice, this often means:
One Big Table (OBT) or a few wide tables
Combining facts and dimensions into denormalised structures
Occasionally mixing granularities within the same model
Downstream KPIs are stored and managed in semantic tools like Cube, Looker, or Omni
The goal isn’t a perfect structure, but rather usable, fast models that support iterative business questions.
Trade-Offs and Real-World Challenges
Modern approaches are appealing for their agility, but they’re not without trade-offs. Teams may run into challenges like:
Loss of clarity: When everything is in one place, definitions and logic can get blurry.
Duplication of KPIs: Without a shared semantic layer, teams redefine metrics across tools.
Query inefficiencies: Wide tables can become bloated and slow for some use cases.
Meanwhile, traditional models can be a burden when agility is needed. If the team lacks deep modelling expertise, strict schemas can become bottlenecks.
Ultimately, each method reflects a different philosophy: design upfront vs design as you go. The best teams often hybridise both.
Why Are Semantic Models Gaining Momentum Now?
Yordan:
Semantic models are having a moment. But why now?
I think it’s a confluence of factors:
The rise of metrics layers like Cube, dbt Semantic Layer, and Omni, which promise consistent KPIs across tools
Frustration with duplicated business logic and metric drift
The need to empower non-technical users without asking them to write SQL
From my experience, this is especially true in cross-functional environments. Analysts, PMs, and engineers often rely on the same data but interpret it differently. A shared semantic model can serve as a contract, ensuring everyone speaks the same language.
However, adoption remains uneven. Semantic tools often require heavy setup, new learning curves, or come with vendor lock-in. As of now, each tool builds its own semantic layer: Cube’s is different from Looker’s, which is different from dbt Cloud’s. Even within dbt, you can only use their semantic layer with their cloud product, not the open-source version.
That fragmentation makes collaboration harder. It’s no surprise that calls for standardisation are growing louder.
Hasan:
I believe semantic models are gaining momentum from the rise of Generative AI. When combined with large language models, semantic models can bring a major shift in how we do analytics and reporting. This has created a strong interest in adopting semantic modelling across many teams.
It feels like a snowball effect. As more people get interested, vendors are also building new tools and platforms around semantic models. That makes the space move even faster. As a data engineer who uses semantic models regularly and is still exploring what they can do, I believe this momentum will last.
The benefits clearly outweigh the limitations, and I’m confident the gaps we see today will get smaller as the tools improve. It’s an exciting time to work with this approach, and I see it playing a big role in the future of data engineering.
I believe that soon, we will be able to just talk to our data and get meaningful insights thanks to the semantic models and LLMs.
Erfan:
In my view, semantic models are gaining momentum now because data governance is becoming more important than ever.
As organisations mature and data becomes more central to decision-making, there's a growing need to ensure consistency, trust, and clarity. A semantic layer plays a huge role here — it helps create a single source of truth for business metrics.
Instead of each team writing their own SQL and defining metrics slightly differently (e.g., "active users" or "churn rate"), semantic models centralize business logic. This reduces confusion, improves accuracy, and makes it easier to govern and maintain your data models across teams.
In short, Semantic models bring order to chaos by simplifying governance and aligning everyone on the same definitions.
That said, implementing a semantic layer isn't free. It often requires:
A clear data architecture
Alignment across teams
Some upfront effort to define and document key metrics
But in the long run, that investment pays off, especially as Yordan mentioned in cross-functional environments where multiple teams rely on shared data.
Use Cases and Value in Practice
1. Self-Serve Analytics
One of the most valuable outcomes of using semantic models is the self-serve analytics. When metrics are defined and maintained centrally, analysts and business users can explore data more independently. They no longer need to rely on data engineers for every report or metric check, and they can trust that the definitions they’re using are consistent across the organisation.
2. Naming and Definitions
Semantic models also help align naming and definitions across teams. It’s common for terms like active users, revenue, or conversion to mean slightly different things depending on the team or tool. By defining these once in the semantic layer and using them across reporting platforms, it may reduce confusion and bring clarity to how metrics are used and interpreted.
3. Safer and Scalable Development
From a development perspective, semantic models make updates and changes less risky. Since metric definitions are stored in one place, we can adjust logic without worrying about breaking dashboards, SQL reports, or downstream tools. This is a major improvement over traditional workflows, where changes in one SQL query can cause unexpected issues in multiple places.
4. Suitable for All Business Sizes
Semantic models work well across different business sizes. Smaller companies benefit from faster access to verified metrics, while larger organisations gain consistency and governance across teams and tools. Regardless of scale, they help reduce duplicated logic and improve how teams collaborate on data.
5. Improving Data Governance
On the governance side, semantic models offer a clearer structure. They make it easier to manage ownership, trace definitions, and understand how data is used across the business. This supports better auditing, documentation, and trust in reporting.
Will Semantic Models Replace Traditional Data Modelling?
Yordan:
This is a big question — and probably the wrong one.
Semantic models aren’t meant to replace traditional modelling. Instead, they abstract business logic on top of whichever physical model you choose , whether that’s a star schema, a flat table, or a hybrid.
That said, we see teams gravitating toward simpler physical models (like OBTs), while moving complexity to semantic layers. Because it gives more flexibility.
Tips for piloting semantic layers:
Start small: one domain, one metric set
Choose a tool that integrates with your current stack
Involve business users early — they’re the real consumers
Document definitions and track metric usage
A semantic layer isn’t a silver bullet. But in the right context, it can simplify complexity.
Erfan:
I don’t think semantic models will replace traditional data modelling. Over time, teams usually figure out what works best for them.
Things change, a new tool or method might come along that adds value, and people will start using it. It’s not about replacing one with another, but about using the right tool for the job.
Semantic models are just one more option to help teams work better with data.
Hasan:
This is a solid “No”. I believe they will become a strong layer that works with our existing modelling approaches. Just like we’ve learned when to use star schema or data vault depending on the needs over time, we’ll also develop clear best practices for when and how to apply semantic layers.
With experience, teams will know where semantic models fit best in their stack and how to use them alongside their current models. It’s not a replacement, but rather it’s an evolution that makes our data systems more flexible, consistent, and accessible.
As for piloting semantic layers, I think Yordan already shared a great recipe above :)
Future Outlook
Looking ahead, the data stack may evolve in two competing directions:
Modelling gets deprioritised entirely. As storage and compute improve, data teams may lean into querying denormalised tables with minimal transformations. Think: "just use the big table" becomes a norm.
AI brings modelling back. As tools like GPT suggest SQL or architectures, they may recommend classic patterns like Kimball or Data Vault — especially for junior data engineers or less structured teams. The twist? Many won’t have the time or skills to implement these well.
As for semantic layers: standardisation is the missing piece. Right now, they’re fragmented, proprietary, and tied to specific platforms. But imagine a world where:
You define a metric once
It’s available in Tableau, Hex, Omni, and your AI copilot
It’s versioned, documented, and owned
That’s the potential. Whether we get there depends on community push and vendor cooperation.
For now, semantic models are a practical middle ground — offering consistency without sacrificing speed. They don’t make data modelling obsolete. But they do make it more usable for more people.
Conclusion
In this post, we wanted to discuss semantic models to provide a wide perspective on how they are shaping the way we model, share, and govern data. Rather than replacing traditional approaches, semantic models act as a complementary layer that brings clarity and consistency to how metrics are defined and used across teams. As adoption grows and tools evolve, we believe semantic models will become a key part of the modern data stack and help teams work faster, collaborate better.
As a follow-up, we’ll soon publish a post on semantic layers and MetricFlow in our dbt in Action series. If you haven’t seen the earlier posts in that series, you can check them out here2.
If you enjoyed this post, you might also be interested in the posts listed below.
https://ivanovyordan.com/
https://pipeline2insights.substack.com/t/dbt-series
 | A guest post by
|
Great panel/intro on semantic models! One challenge that I don't feel like it was covered enough in this post is about the need to manually document the semantic model, and the amount of time it takes. I actually just shared something about it today (coincidentally)!
Curious what you think: https://journey.getsolid.ai/p/semantic-layer-for-ai-lets-not-make?r=5b9smj&utm_campaign=post&utm_medium=web&showWelcomeOnShare=false
This is a great read. I’m really hoping semantic modelling remains in the age of AI, because I feel without it, human understanding of the data will become more and more elusive. Proper modelling, to me at least, is a map to understanding our data.