I use the solution for transformation. When we perform the ELT process, we need to transform the data according to the business requirements. We can also use the tool for testing.

The product is developer-friendly. A person who understands SQL can develop the transformation. We do not have to learn a lot of things like we do for new tools. The tool has good testing and data quality features. Implementing Slowly Changing Dimensions through dbt has been easy. It is very easy for a beginner to use the product.

The tool provides multiple technical advantages if we use Snowflake. It is a good transformation tool because it is SQL-oriented. It has data lineage, data quality, and workflow scheduler.

The solution must add more Python-based implementations. Transformation tools require Python-based implementations. It would give developers more freedom to use SQL or Python. We can use Python, but it is not that user-friendly. The product doesn't have a lot of optimization options.

I have been using the solution for almost three years.

There are no problems with the product’s stability.

We have at least 25 to 50 users in our organization.

The solution is deployed on the cloud. It can be deployed on AWS, Azure, or GCP. The initial setup is easy.

The solution’s pricing is affordable.

We also use stored procedures and Talend. They are not replaced by dbt completely. We use dbt only for the transformation process. My recommendations would depend on an organization’s requirements and problems. I will recommend the tool to others. The product is developer-friendly. However, it is still dependent on the data warehouse for big data and optimization.

It's just a SQL transformation tool. It doesn't have a lot of optimization options like Spark. It's a good tool for Snowflake. If it were only for Snowflake, I would have rated it an eight out of ten. However, there are other data platforms.

Overall, I rate the tool a six and a half out of ten.

We use the solution to deal with data transformations inside different organizations.

You need some knowledge. Dbt has a more flexible learning curve than other tools. You need some experience to handle big data workloads but with less experience, you can get started.

They help us orchestrate different transformations. With Dbt, you can automate the orchestration of transformations without thinking too much.

SQL statements that beyond DML, are not possible. Currently, they are not possible in Dbt. Having more features in SQL statements will support us.

Another issue is the terms of data ingestion because Dbt requires sources to be defined, and you need to handle data ingestion with other tools. So having a data injection tool integrated within dbt will be awesome.

I have been using dbt for three years.

It's very scalable because it's open source. You can spin up different EC2 or different compute instances to run VVT. We have 14 professionals using this solution. I rate it a nine out of ten.

I store procedures calling within dbt statements. You can only use a selected statement in debt. If you want to use more advanced or more complicated SQL features, they are not supported right now by Dbt, so that can be a challenge.

It is cheap because dbt is open source. If you compare the pay-per-service of Dbt with the open source option you can manage. We are managing the solution, when we were acquiring service from them. It was also cheap compared with the engineering cost that implies managing the the infrastructure.

I have had the opportunity to teach one of the tools to level entry engineers because it's easy to learn and easy to maintain. It's pretty useful.

It depends on the architecture and the amount of company's data or the people that I'm going to advise. If you're starting a data engineering team and you don't have a lot of big data workflows, I would recommend Dbt. I recommend our tools for more advanced workflows but for starting, I recommend 100% Dbt.

Overall, I rate the solution a nine out of ten.