Hey there HN. lea is a tool we developed over the past year at Carbonfact. Carbonfact is a platform that helps fashion brands decarbonize. We believe in doing this in a data-driven way, and lea is a cornerstone for us.
- I don't like to have to put {{ ref('source') }} everywhere. I think the tool should parse dependencies automatically. I wrote more about this here: https://maxhalford.github.io/blog/dbt-ref-rant/
- I don't like the idea each .sql file has to have an associated .yml file. It feels better to have everything in one place. For instance, with lea you can add a @UNIQUE tag as an SQL comment to unit test a column for uniqueness.
Moreover, although dbt brought a shift in the way we do data (which is great) it's very straightforward under the hood. It boils down to parsing queries, organizing them in a DAG, and processing said DAG. dbt feels bloated to me. Also, it seems to me some of the newer cool features are going to be put behind a paywall (e.g. metric layers)
Lemaxoxo|2 years ago
JeanEdern|2 years ago
Lemaxoxo|2 years ago
- I don't like to have to put {{ ref('source') }} everywhere. I think the tool should parse dependencies automatically. I wrote more about this here: https://maxhalford.github.io/blog/dbt-ref-rant/ - I don't like the idea each .sql file has to have an associated .yml file. It feels better to have everything in one place. For instance, with lea you can add a @UNIQUE tag as an SQL comment to unit test a column for uniqueness.
Moreover, although dbt brought a shift in the way we do data (which is great) it's very straightforward under the hood. It boils down to parsing queries, organizing them in a DAG, and processing said DAG. dbt feels bloated to me. Also, it seems to me some of the newer cool features are going to be put behind a paywall (e.g. metric layers)