I have nothing against dimensional modeling per-say, just the uptime effort (and initial feedback lag) that it generally brings with it in the beginning.
Another issue I've observed with teams trying to formalize their modeling "too" soon is a confusion in the models created. I find that it's sometimes difficult for teams to understand what should be in each model, how to separate the different dimensions, etc. Hence my emphasis on starting naively in the beginning and then aiming for that dimensional model when things start becoming clearer...
Author here: yeah I ended up insisting a bit much on dbt as a basis although the method I'm describing in the article can definitely be applied to any kind of modeling framework (or lack of)
Anyway, please let me know what you think of the general method and the bottom-up VS top-down approach ;-)
I definitely agree with the over-hype making simple mundane tasks way harder than they should be.
So yeah, do NOT over-engineer!!
But, on the other hand, doing everything with a single Postgres and spreadsheets seems to go with the hammer-to-nail adage.
And all too often, you end up with unmaintainable duck-taped hack-arounds...
Which is clearly NOT better (nor necessarily worst) than the over-engineered solution.
In some cases (maybe not 1% but clearly not the majority either), it does make sense to look at other tools that might be available.
That being said, there are waaaay too many options to filter through, because of that darn hype bubble.
Meh, depends on the data teams (and their chosen suite of tools)... Or on the Excel users
Both sides can either hack together horrible work-arounds (a matter of "when you have a hammer, everything looks like a nail...") as well as brilliantly thought through solutions.
Each tool should be used for it's best use cases, but not bent into what it wasn't designed for!
IMHO spreadsheets excel at intuitively manipulating the data ON the data itself.
While "modern data" tools (especially dbt) try to convert date teams to use developer best practices... At the expense of less intuitive/direct manipulation of the data.
That being said, I think there are also things we could explore in that space: how to make the modern data stack more intuitive?
I have nothing against dimensional modeling per-say, just the uptime effort (and initial feedback lag) that it generally brings with it in the beginning.
Another issue I've observed with teams trying to formalize their modeling "too" soon is a confusion in the models created. I find that it's sometimes difficult for teams to understand what should be in each model, how to separate the different dimensions, etc. Hence my emphasis on starting naively in the beginning and then aiming for that dimensional model when things start becoming clearer...