8 dbt Myths That Need To Be Busted

Image courtesy of imgflip.com

On the 7th of January 2021, I started my newsletter about data for one reason: Because of an open-source tool called dbt.

I got introduced to dbt early, together with an introduction to the fishtownanalytics mentality around ELT. I was blown away by their visionary approach and the ease of use of dbt.

But because I should’ve heard earlier about dbt and their approach, I started my newsletter to stay on top of the data world for good.

Today, 3 years later, dbt has made a lot of progress, fishtownanalytics rebranded as DbtLabs, launched a commercial cloud offering and tons of features for the open core dbt.

Dbt has become a major engine, and the competitors have grown up. Dbt changed a lot from the easy-to-use open source project I learned about at the end of 2020.

As a result of this fast development from a small open source project to a large commercial product, many myths still surround dbt.

I’m here to discuss the 8 myths I find most often, not to get you away from the tool, but to help you make the most of it!

Myth #1: dbt is SQL only

Quote by Madison Schott

That’s the claim even experienced analytics engineers like Madison Schott make. But it is simply not true anymore. The minimum amount of things you need to know to get started with dbt are:

1. SQL
2. The Jinja reference structure used in dbt, hello {{ reference }}
3. The structure of a dbt project (Madison has written another good article about this)
4. The data model that dbt uses with raw/seed and transformed data
5. A tiny bit of dbt commands

That’s already a lot. In 2019, dbt was mostly SQL, but since then, features exploded around references, packages, macros, the structure of dbt projects and the dbt commands.

Today dbt is a lot, but most of it is not SQL.

Myth #2: Dbt is easy to learn