
dbt Platform
FinOps billing data has become verifiable and actionable for accurate cloud cost ownership
What is our primary use case?
We have a FinOps use case, which means we are processing billing data from cloud providers. We use dbt to create data models around billing and convert them into insights where we can find cost optimization, and also a reporting function, ensuring that the cost in the cloud infrastructure is attributable to the team, the organization, or whoever is responsible for that resource.
What is most valuable?
When we started adopting agentic engineering, we were looking at a tool that could help us do some verification. dbt came up as the leading tool that could support the workflow that we have envisioned with the team because we would not want to use AI without a capability to do verification and to do proper testing on data models.
What needs improvement?
The capability for doing proper testing in dbt is quite recent. One thing that dbt still lacks is native support for knowing the coverage. In traditional software engineering, once you have a tool packaged as a testing tool, you immediately have a number beside that tool. If you do testing, it can tell you how much of the source code is covered by tests. A good coverage could be that 90% of all tests or 90% of the code is covered by tests, and you can see that bad code potentially has 20% uncovered tests. In the case of dbt, this number is not something that they support out of the box, and you have to be creative to extract this number.
For how long have I used the solution?
I have been using dbt for about a year.
What do I think about the stability of the solution?
So far, I have not experienced any stability issues, but I can attribute this to our workflow being more automated. Our commands, when we issue dbt, are predictable. We rarely have to run a dbt command ourselves, and if we have to do that, we have playbooks, which means everything is documented whenever we need to do something with dbt. When you are issuing dbt commands, you have a tendency to alter active data, which depends on if you alter the datasets, the reports which upstream users are looking at, whether management or those using our FinOps tooling, will be affected. We have streamlined the process of running dbt to avoid executing things that could accidentally be an issue in production.
What do I think about the scalability of the solution?
For our small team of three engineers, dbt is super stable at the moment. When thinking about scalability, every engineer has to have their own workspace. If everyone is playing around with dbt commands, there is a high tendency that there will be congestion. If I update a model, another engineer updates a model, and then another engineer updates the same model, then it is going to be an issue. Every head needs to have its own separate workspace, which means every workspace will have to have test data and the same baseline schema. This is the current setup I see for dbt, so as long as you understand that this is the condition for using dbt, every engineer that needs to work on the codebase needs to have their own individual workspace. This is quite different from traditional software engineering product teams, where people can share a test environment. For dbt, this is not the case, so everyone contributing to the code needs to have an individual workspace, which makes it less scalable than other tools, but this is really because dbt is a data-related tool, not the fault of the system.
How are customer service and support?
There is an active community, but to be honest, I just have not had time to engage or ask around. I think when the problem is medium to high for us, there will be a bit of pressure, but for now, this is more of a wishlist rather than something that is restricting us.
How was the initial setup?
Being already familiar with the DevOps stack, so CI/CD, it is not a high bar for learning for me. I can imagine that some people could feel a bit intimidated by it because I know some colleagues who have been working in data engineering and they have difficulty adopting or understanding how you set up a tool such as dbt. I would say it depends on the background and the skills inside the software engineering team.
What's my experience with pricing, setup cost, and licensing?
We are unfortunately, or fortunately, depending on the perspective, not using dbt Cloud, which is the paid option. We are using the open-source version, which is dbt Core. For our use case, this is sufficient at the moment, but we will see eventually if there is really something interesting that we would like to leverage in their paid offering. For now, using the open-source version is sufficient for us.
Which other solutions did I evaluate?
I did read about a few other tools such as Bruin, or maybe some teams are actually using just Python testing, but those solutions are not as close to what you would be using if you are developing the data engineering part of FinOps, which is closely tied to SQL as a language. The other tools are more geared toward other programming languages, and dbt is quite unique in that it is the only one supporting testing with SQL as a first-class language.
What other advice do I have?
I have been working in my current field for more than 15 years.
We take care of maintenance in terms of checking compatibility of upgrades. For example, dbt released a newer version in Rust that is a bit faster in terms of performance, but it is not yet compatible with our AWS data analytics stack, so we cannot switch to Rust even though we would prefer to. We have to wait for the connector to AWS if someone builds that. This is the problem with open source: if someone does not build it, potentially we are stuck with Python. But it is still working for now, so in terms of maintenance, if you want to maybe go for the state of the art, that could be a use case to be on a paid subscription to dbt, and then you tell them you would prefer this to be supported in AWS so we can merge to the latest version in Rust and adopt a faster workflow.
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Simple SQL-Driven Materializations with Powerful Lineage
Great UI Makes Data Lineage and Flow Easy to Understand
Simplifying Data Transformations
Data pipelines have grown in complexity and now support automated tests and rich documentation
What is our primary use case?
My main use case for dbt is data pipelines. I build data transformations and usually construct analytics pipelines.
What is most valuable?
I use dbt to handle transformations because it is really good at generating automatic documentation. dbt orchestrates and automates workflows, and it provides visualization of the data. dbt generates documentation from the code automatically. I also use tests where I can define automatic tests that will run.
dbt has positively impacted my organization by allowing us to expand the ceiling of complexity because once we have written the SQL, we can manage significantly more complexity since we are not spending all of our time doing it ourselves.
What needs improvement?
dbt can be improved by introducing Python. Ideally, I would want to be able to orchestrate across the DAG and have both Python and SQL combined. The last time I used it, it was not able to visualize that on the DAG.
The main issue I have had with dbt is that when I start a project inside dbt, the structure I have to use is somewhat strict. In terms of reusability and abstraction, it is really good inside a project, but as soon as I try to create a package, something that others could use or make my work reusable, it was not very good. dbt was not very good at package management.
For how long have I used the solution?
I have been using dbt for four years.
What do I think about the stability of the solution?
dbt is stable.
What do I think about the scalability of the solution?
dbt's scalability is probably where it shines the most; it is really scalable compared to using just SQL.
How are customer service and support?
I have not had to use customer support for dbt. dbt has a very strong community. I would rate the customer support as really good since I have never had to use it; I can go on the forums and get most of my questions answered.
Which solution did I use previously and why did I switch?
I did not previously use a different solution before dbt; every time I have used dbt, it was always embedded.
What was our ROI?
I have seen a return on investment from using dbt. I would say that you needed fewer people. You take your time, but I do not have concrete metrics.
What's my experience with pricing, setup cost, and licensing?
My experience with pricing, setup cost, and licensing for dbt is that dbt is open source for its core modules, so the pricing, setup, and everything was really good.
Which other solutions did I evaluate?
I did not evaluate other options before choosing dbt.
What other advice do I have?
My advice for others looking into using dbt is to read the documentation; it is not that difficult to use. I would rate this review an 8 out of 10.
Scalable, Easy-to-Use Data Pipelines That Shine with Snowflake
Streamlines Data Transformation with Best Practices
Easy-to-Use DBT for Version-Controlled SQL Models
Effortless Data Transformations with dbt
Data transformations have streamlined complex reporting and support reusable macros for multiple clients
What is our primary use case?
In Power BI, I am currently creating solutions for this particular organization or team. I work end-to-end, providing the complete solution by understanding business requirements and KPIs, and building dashboards from end-to-end. This includes working with Fivetran, DBT, Python scripts, and other tools. I have been working with dbt for three years.
What is most valuable?
dbt is generally used with Jinja technology, and Jinja format is what I utilize. The structure of the scripts is different from other tools, and it is quite versatile, allowing me to use Python, SQL, or any other language. dbt mainly handles semi-structured data quite effectively, supporting major business transformations. dbt is used for transformation purposes, and I provide the business logic in the dbt scripts which run under the Git pipeline. Currently, due to cost cutting, we revised our technology strategy and created the pipeline with dbt for budget purposes. The database is loaded and business transformations are done through dbt, and it has a separate pipeline which loads the data into the database. We use Git or Bitbucket for versioning, and the code is stored there, with all business logic incorporation done within dbt.
dbt has reusable macros that can be created and used in multiple models, which I find very valuable. When I create the final tables, they are in the model folder, and under the model, these final tables are created. It also has a structured way of handling data, allowing me to mold it out effectively. A main feature is the ability to manage different pipelines, especially since I utilize Bitbucket for pipelining processes. In this, I can handle the scripts, determining which job should run based on various dependencies. I write loading processes in the .YML file, which I implement inside Bitbucket and in dbt scripts. The macros allow me to write multiple utilities or multiple scripts that can be reused in different models effectively.
The way dbt handles semi-structured data is by allowing me to easily manage any requirements or KPIs that come with it. I can handle it in the dbt scripts.
What needs improvement?
The initial setup of dbt is somewhat complex. Writing the scripts requires understanding Jinja technology, as the code writing structure is different compared to other tools, which can be challenging for developers unfamiliar with it. However, once I learned the structure, it became a robust tool for handling data, including semi-structured data like JSON.
dbt itself is quite extensive, and while many features are available, I often focus on common features. For unusual activities, I may not have enough experience to determine necessary changes or new features. Currently, I cannot suggest any changes or additions, primarily because I am working with structured data and not encountering many challenges with the dbt scripts. It successfully achieves our requirements.
What do I think about the stability of the solution?
The reliability of data in dbt is strong. When I conduct dbt tests, the data processed in the data warehouse performs exactly as expected. There are no interruptions during processing, ensuring consistency.
What do I think about the scalability of the solution?
dbt is quite scalable since it has its own feature set for incorporating business logic, while the data storage occurs in Snowflake, allowing me to handle complex scenarios as needed effectively.
How are customer service and support?
I have not had to communicate with dbt's technical support or customer service thus far, as my internal organization typically handles complex scenarios. If my DevOps teams are unable to resolve issues, I would consider reaching out, but that scenario has not arisen to date.
Which solution did I use previously and why did I switch?
Regarding pricing, I am not deeply involved in that aspect. However, due to pricing increases, we have transitioned to using dbt pipelines for running our jobs. Fivetran was previously our tool, but after they raised their prices, we started using dbt at the beginning of 2025. Overall, I find dbt to be optimized compared to other tools.
In evaluating other solutions, we have our own data warehouse in Snowflake, where we can explore features such as Snowflake pipes for structured data. Additionally, I have worked with Teradata and manipulated data using temporary tables. Snowflake offers more features than Teradata, allowing coding in both Python and SQL, making it a versatile option alongside dbt for loading, storing, and processing data.
How was the initial setup?
The initial setup of dbt is somewhat complex. Writing the scripts requires understanding Jinja technology, as the code writing structure is different compared to other tools, which can be challenging for developers unfamiliar with it. However, once I learned the structure, it became a robust tool for handling data, including semi-structured data like JSON.
Which other solutions did I evaluate?
Regarding pricing, I am not deeply involved in that aspect. However, due to pricing increases, we have transitioned to using dbt pipelines for running our jobs. Fivetran was previously our tool, but after they raised their prices, we started using dbt at the beginning of 2025. Overall, I find dbt to be optimized compared to other tools.
In evaluating other solutions, we have our own data warehouse in Snowflake, where we can explore features such as Snowflake pipes for structured data. Additionally, I have worked with Teradata and manipulated data using temporary tables. Snowflake offers more features than Teradata, allowing coding in both Python and SQL, making it a versatile option alongside dbt for loading, storing, and processing data.
What other advice do I have?
dbt SQL model is what I create, and I develop different macros and utilities that handle various client databases effectively, as each client has a separate database but maintains the same table structure. For instance, I have created J&J_DWH for Johnson & Johnson, with most clients holding the same data structure, but there can be exceptions where certain clients might have fields missing. To manage this, I write checks in the dbt scripts so that if a specific column is not present for a client, the code does not stop. It takes measurable steps and creates a column with the same name but with null values. This utility is essential for handling complex scenarios across multiple clients.
The testing framework in dbt is useful, as I run dbt tests based on the number of clients, specifically running tests for a few clients based on their names. It generally runs unit test cases in the testing environment. The scripts I created validate successfully, and I can trace errors in the logs to identify any issues. In the .YML file, I document relationships, uniqueness tests, and other necessary details. Before final data loads, I run dbt tests to confirm that the data is accurately loaded into the table.
Regarding dbt's documentation site generator, it is extremely helpful for project transparency, particularly in complex scenarios. Organizations provide good documentation, and I refer to dbt.org to resolve issues or clarify doubts on activities I have not previously handled. This aids in ensuring data transparency and assurance during review processes with clients, enabling me to justify my methods based on the documentation and organizational standards. I would rate this review nine out of ten.