A Year with Omni: A Look Back
We’ve been using Omni at Molotov for almost a year now.
Since then, several people around me have asked what I thought about this solution, which has been getting quite a lot of attention lately.
The context
We were starting a migration of our Data stack when the question of the BI tool came up.
Until then, we had been using Tableau. The tool was a huge source of frustration for our BI developers/Data Analysts/Analytics Engineers (call them whatever you want). They were spending too much time dealing with issues specific to the tool, rather than focusing on data or business needs.
On the business side, users had largely abandoned the solution: it was slow and not very user-friendly. Their requests also took too long to get addressed.
I had just joined the company. The team itself was relatively new, but it had already made good progress migrating our transformation layer to dbt.
As for the data warehouse, we were moving from Snowflake to BigQuery.
New team. New transformation layer. New data warehouse.
The perfect setup for a POC.
My role
I’m a Data Engineer, so my day-to-day use of Omni isn’t as extensive as that of an Analytics Engineer or Data Analyst.
I mainly worked on:
- setting up and configuring the tool;
- the user and access management strategy;
- creating the first training materials to help the team get up to speed during the POC and the first few weeks;
- continuous integration (CI) and the validation workflow (yes, for a BI tool);
- some monitoring and FinOps needs, so I did end up using the tool myself.
So my perspective on the adoption of the tool is more platform-oriented.
For very specific questions about advanced day-to-day usage, feel free to ask in the comments. I’ll pass them on to the people who use Omni more intensively than I do.
1. A steeper learning curve, but for good reason
The learning curve is steeper than with other BI tools, especially if you want to get the most out of what Omni has to offer.
A big part of that comes from the Shared Model, Omni’s shared semantic model.
With Omni, working on data doesn’t stop at the transformation layer of your stack. It continues inside the tool.
You’re not simply connecting a few tables and then building charts. You continuously develop a semantic layer: a logical model designed for analytics, with concepts such as Views, Relationships, Topics, relationships between datasets, access rules, definitions and context specific to your business. Information that both the tool and the AI need to properly understand your requests.
That requires an investment.
You need to understand how these different layers fit together, decide what should live in dbt and what should live in Omni, structure the model, and then help the team adapt to this new way of working.
That’s precisely what explains the learning curve. But it is also, in my opinion, Omni’s main strength.
Once this model is in place, it becomes the foundation for exploration, visualizations, dashboards and AI. Shared definitions and relationships no longer need to be recreated in every chart. Business context can be defined once, then reused and extended as needed.
In other words, Omni doesn’t remove complexity. It moves it.
It requires more work from the Data team when building and evolving the model, but saves users a lot of that work when they explore the data.
And that’s an important point for what comes next: the learning curve is mainly for the Data team. For business users, the goal is precisely the opposite.
2. A strong dbt integration
The integration with dbt is very deep. Deep enough that it could almost justify moving to Omni on its own, or conversely, significantly reduce its appeal if you don’t use dbt.
You can sync your dbt project (you could almost say link it) with Omni and have your dbt models and Omni model evolve in both directions, automatically.
Concretely, you can develop and evolve your dbt models in your development environment, immediately see your changes in Omni — its model, visualizations and dashboards — exactly as they would look in production, and work in an identical environment before delivering everything to production with confidence.
There is also the concept of branching in Omni, which isn’t limited to its dbt integration (although the integration makes it even more useful). You can very easily switch Git/dbt branches directly in Omni to work on visualizations based on models that are still under development. Test. Move on to something else. Come back to it later.
We don’t use it ourselves, but the workflow also works the other way around: you can start by designing your model directly in Omni (for example, by defining the data and metrics you want), then have Omni generate the corresponding dbt models and push them to your dbt project/repository.
3. Topics: a concept that helps governance and promotes autonomy
Topics are, in my opinion, one of Omni’s most interesting features.
There are probably equivalent concepts in other solutions, but the concept is particularly well designed and implemented here.
The idea is to build business-oriented areas of analysis (for example Sales, Subscriptions, Marketing, etc.) by selecting the relevant data from the Shared Model. You therefore don’t give access to the entire model, but only to a coherent scope adapted to a specific use case.
Get Eren GUNDAG’s stories in your inbox
Join Medium for free to get updates from this writer.
This makes users much more autonomous in their analysis and exploration, while still giving you control over the data they can access. Analytics teams can therefore do real curation work: selecting the right dimensions and metrics, adding descriptions, business context, definitions, usage examples, etc.
Topics are therefore not just about simplifying the user experience. They also provide a knowledge base that improves the quality of analyses and reduces the risk of misinterpretation.
They also play an important role for AI. By providing a well-defined business scope enriched with context and definitions, AI has a better understanding of the concepts being used and can produce more relevant answers. This is, in my opinion, one of the reasons behind the quality of the results obtained with Omni’s AI features.
4. AI that actually works
I was rather skeptical about Omni’s AI promises (especially Text-to-SQL) before trying it. I’ve had a mixed experience with this kind of tool. I worked with Databricks AI/BI Genie very early on. It was promising, but full of limitations.
Since then, reasoning models have improved significantly, there has been a lot of talk about context engineering, and the work done by developers and tools increasingly consists of providing AI with the right information at the right time.
In the end, I was pleasantly surprised.
With the Shared Model, your business context, and AI’s ability to explore your data, analyze the results and correct its mistakes, it becomes particularly relevant.
What makes it relevant is that it doesn’t rely solely on the semantic model: it also analyzes the data to validate its assumptions, adjusts its reasoning when it detects an inconsistency, and tries again before reaching an answer.
I found it more relevant than what I had seen with AI/BI Genie (although my comparison dates back to late 2024, when the product launched).
AI is integrated into pretty much every step:
- assistance with designing the Shared Model;
- analytical questions in natural language (Text-to-SQL), using both the model and the data;
- generating answers as text, tables or charts;
- automatically generating dashboards.
It is also worth noting that you can choose which language model is used for AI interactions.
On the other hand, Omni’s AI usage pricing model is currently evolving. We had the opportunity to use it with relatively few constraints, which allowed me to fully explore its capabilities and contributed significantly to the excellent impression I got from it. In the long run, more measured usage, particularly depending on the cost, could however limit this freedom to explore and, consequently, the “wow” effect.
See you in a year.
5. Software development best practices applied to BI
The Omni model is version-controlled in Git, which makes it possible to apply software development best practices: branches, code reviews, history, etc.
I really like this philosophy. It reminds me of what dbt brought to the BI/Analytics ecosystem a few years ago: treating analytical models as code, with everything that implies in terms of quality and collaboration.
6. A product that evolves very quickly
In just a few months, many important features have been added. The team also seems very receptive to user feedback and quick to take it into account when improving the product or developing new features.
I’m probably already behind. But you can do a lot of things with it.
My take
I would mainly recommend Omni to teams that want to invest in their analytical model and, ideally, use it with dbt.
If the goal is simply to build a few dashboards or make nice-looking charts, I’m not convinced that the investment in the learning curve is justified. A large part of Omni’s value comes precisely from the Shared Model, its integration with dbt, and everything this enables in terms of exploration and AI.
Once the model, Topics and access rules are properly defined, a large part of the work can be left to data consumers.
At Molotov, we obviously continue to build dashboards and initiate some analyses. But in many cases, we could stop at developing the model and the Topic, and let users explore on their own.
The tool is intuitive and allows them to explore the data within the scope we have defined, ask questions to the AI, perform ad hoc analyses, build dashboards in a few minutes, create alerts or export their results.
They can answer their questions, but more importantly, come up with new ones. Questions they might not have thought of, or might not have been able to answer otherwise.
Ultimately, that’s the goal: enabling people to make better decisions without the tool or access to data becoming a constraint or a source of friction. Quite the opposite.
At least in our case, the tool has been fully adopted by the Data team, but even more so by data consumers. And in record time.
The learning curve is mainly for the Data team.
When it comes to AI, it is natively integrated into the tool and into many different stages: from designing the Shared Model to exploring data, creating visualizations and building dashboards. And that’s precisely what makes it interesting: it is part of how the product works rather than a gimmicky feature added on the side.
It is particularly relevant, provided that you’ve done the necessary curation work on the model and its context.
Omni even offers an MCP, which should particularly delight generative AI fans and integrate nicely into your architectures (I’m thinking Slack, for example) — and might even improve this article’s SEO with the sheer number of these keywords.
A few limitations
Beyond the learning curve, there are still some missing features, particularly around security.
For example, some options for managing permissions directly at the Data Warehouse level are not yet available with BigQuery. Queries notably go through a shared service account, although Omni provides other mechanisms, such as Attributes, to manage access at the row and column level.
This is just one example of the small limitations you can still encounter with a relatively young product.
But Omni evolves quickly. Very quickly. New features are released regularly, and the team seems particularly receptive to user feedback.
The product is young, but already mature. And I’d be curious to do the same review again in a year.
