Data Arrow was born from the frustration of seeing business logic scattered across SQL, dashboards, dbt models, and undocumented assumptions.
The goal is to help teams convert messy technical structures into clean, understandable, and executable data models.
It is not only about generating code.
It is about helping people understand the data model before they build on top of it.
Because in the end, a data platform is only valuable when both the business and the technical teams can trust the same model.
I did not build Data Arrow because the world needs another diagramming tool.
I built it because I felt there is a missing layer between business thinking and data engineering execution.
Many tools are good at execution.
Many tools are good at visualization.
But very few tools help someone understand:
What is the grain?
Is this a fact or a dimension?
Can this SQL be converted into a cleaner model?
How does this dbt lineage map back to business concepts?
Can this business model become executable dbt code?
Can the same model also become a graph model?
That is the gap Data Arrow is trying to solve.
There are several complexities in modern data modelling, and many of them actually start with the fundamentals.
Even with Kimball, one of the biggest challenges is translating business requirements into a clear, consistent model while staying true to dimensional modelling standards.
That is exactly why we created Data Arrow — to help organize the different pieces of a business requirement and systematically translate them into a structured Kimball-based data model.
At the same time, dbt is sometimes mistaken for a data modelling platform. In reality, dbt is primarily a powerful data transformation engine. The business model and modelling decisions still need to come first.
Data Arrow is intended to bridge that gap:
Business Requirement → Dimensional Model → dbt Transformation
More than happy to have a discussion, walk through the approach, or offer access to the public preview free of cost for anyone interested in trying it.