dbt Reviews

My main use case for dbt was transforming messy, extracted financial data into clean, production-ready datasets. Let me give you a concrete example. We would extract trial balance data from PDFs using OCR and then feed it through our GenFin mapping workflow. Before that data reached our GPT-4 model for classification, we used dbt to normalize account codes, handle currency conversions, work with UAE and multi-currency scenarios for UAE compliance, and create aggregations by cost center and account type. So dbt's job was essentially to take a raw extraction output, validate it against our schema, handle any missing values or duplicate entries, and then materialize clean tables that our LLMs could reliably work with.

There was one more important place beyond just transformation. dbt gave us visibility into data quality throughout the pipeline. We built tests into our models, including checking for null values in critical fields such as account numbers, ensuring amounts were numeric and within expected range, and validating that our transformed data matched the source record counts. This was critical because if there was a gap between extraction and transformation, we would catch it before it hit the LLM. The dependency graph in dbt was invaluable when we had issues downstream in our mapping or disclosure notes workflows, as we could trace back through the DAG.

The most concrete outcome was a significant reduction in data errors reaching our downstream AI models. Before dbt, we were catching bad extractions only after the LLM had already processed them, which meant manual rework. After implementing dbt's testing layer, we caught roughly 70% of those issues at the transformation stage itself, before they ever touched the model. Processing speed also improved because dbt's incremental models only processed the delta into new records. Our nightly reconciliation runs for UAE corporate tax workflows dropped from around 40 minutes to under 10 minutes. The less obvious win was team confidence. Our chartered accountant clients started trusting the outputs more because we could show them the full transformation chain.

The shift in client trust was really tangible. Before dbt, when we delivered a mapped disclosure notes document, clients would ask us to walk them through how we arrived at the specific numbers. We would have to manually trace back through extraction logs, which was time-consuming and sometimes incomplete. After dbt, we could literally show them the DAG, the dependency graph, and say, here is your source PDF, here is where we extracted the account code, here is the normalization rule we applied, and here is the aggregation, and here is your final mapped output. It is all documented and testable. That transparency eliminated a huge amount of back-and-forth. One specific example involved a client who was questioning why a particular cost center total did not match their internal records. With dbt's lineage, we traced it in minutes, found a rounding rule that needed adjustment in one model, fixed it, and reran the pipeline. The client saw the complete audit trail. That kind of visibility is what builds trust in a financial team.

One thing I would add positively was how well dbt's incremental models handled our late-arriving data scenarios. In financial processing, you often get corrections or amendments to documents days later, and incremental models let us efficiently merge those without full refreshes. That was really valuable for our UAE compliance workflows where reconciliation amendments came in batches.

dbt's incremental model let us handle late-arriving data efficiently without reprocessing everything. That clean output then fed directly into our GPT-4 structured output parser for financial mapping. The workflow fit really well because dbt gave us clear data lineage. We could trace any number of our final mapping output back to the source extract. That is critical in financial-based reporting, where auditors need to see the full transformation chain. For us, the standout features were the testing framework and the dependency graph. The tests, especially custom tests for financial data like validating that debits equal credits, caught a lot of our data quality issues early.

dbt's incremental model was key here. Rather than representing the entire dataset every run, dbt only touched the new or changed records, which kept our pipeline efficient as document volume grows. That said, dbt's scalability is fundamentally tied to your underlying database. In our setup, we managed performance by being deliberate about materialization strategies, using views for lightweight transformations and tables for incremental models for heavy aggregations.

As for something I wish we had, dbt's native support for Python transformations came later, and we did some complex financial classification calculations that felt clunky in pure SQL. We ended up writing Python in our n8n workflows and then fed the results back into dbt, which created a bit of a split-brain situation. If we would have had dbt Python models earlier, we could have kept that logic unified.

Managing multiple reporting standards was our biggest operational pain point with dbt. We were running UAE corporate tax compliance and IFRS disclosure workflows simultaneously for different clients, and dbt does not have a native concept of multi-tenant or multi-standard project organization. Everything lives in one flat structure, so we had to build more conventions: separate schema folders for IFRS models versus UACT models, custom macros to tag models by compliance regime, and environment variables to control which set of transformations run for which client.

I have been working with dbt for approximately one and a half years.

dbt has been very stable.

For our use case, dbt scaled well. We were processing large volumes of financial documents, hundreds of trial balances, balance sheets, and invoice sets, and dbt handled the transformation layer without issues.

dbt's customer support varies depending on which tier you are using. We ran dbt Core, which is open-source, so there is no direct vendor support. The community support is actually quite good, and the dbt Slack community is also very supportive. We found answers to most of our questions through the docs and community. If we would have been on dbt Cloud, there would be dedicated support, but the pricing did not work for our team size. For a bootstrapped FinTech team in India working on UAE compliance workflows, the cost-benefit was not there.

Before dbt, we were handling data transformation in a more ad-hoc way. We had Python scripts and custom SQL queries scattered across our n8n workflows, our automation platform. When we extracted financial data from PDFs using Tesseract OCR and LLM extraction, we would clean and transform it using Python code nodes within n8n. There was no clear lineage. If the number was wrong downstream, tracing back through n8n workflow logic was painful.

We did evaluate alternatives before committing to dbt. We looked at a few options. Apache Airflow was one. It is powerful for orchestration but felt like overkill for our use case and would have required significant DevOps overhead to manage. We also considered Talend and Informatica, but those were enterprise tools with enterprise pricing, and we were a lean team at Radiant Services.

The most concrete outcome was a significant reduction in data errors reaching our downstream AI models. Before dbt, we were catching bad extractions only after the LLM had already processed them, which meant manual rework. After implementing dbt's testing layer, we caught roughly 70% of those issues at the transformation stage itself, before they ever touched the model. Processing speed also improved because dbt's incremental models only processed the delta into new records. Our nightly reconciliation runs for UAE corporate tax workflows dropped from around 40 minutes to under 10 minutes. I would rate this product an 8 out of 10.

I am working with one of our enterprise customers, managing their newly established cloud warehouse. They are using Snowflake and we are using dbt to manage all the transformation and views and tables in Snowflake. I am not currently working with Cribl, but I used to work with it for almost three years. Currently, I am working with dbt and Snowflake stack.

dbt is a tool that is basically SQL and a little bit of Python, which is somewhat low entry-level, so many of the engineers can use it as well as the analysts. Multiple teams from the business side can use it as well if we allow them. Performance-wise, it mainly depends on the platform that hosts it, whether it is Snowflake or Databricks or BigQuery. There is not much complication. Of course, there are the benefits of having code, so you have a software development lifecycle; you can use version control, testing, and documentation.

I would say the best feature or the most desirable feature for dbt is the ability to write everything in code. It is treating data the same way that Ansible did or Terraform did for infrastructure as code. Now you can code the pipeline instead of using SSIS and Apache NiFi and even Informatica PowerCenter. All of these tools are GUI-based tools. They have a low entry barrier, but you cannot really integrate them in a CI/CD pipeline, for example. For dbt, we can create those. More recently with the advances in AI, LLMs, and code assistant agents, we can hugely leverage those in dbt because I can simply ask the agent to write the code or write the model. However, you cannot really ask them to draw any SSIS package or an Apache NiFi flow, for example.

I think that dbt helps us quite a bit because it exposes a little bit of the functionality of Snowflake directly to us. We can use it with ease because we have some experience with Snowflake and we know what controls to adjust. Because we are a team of multiple individuals, we need to collaborate. Without version control, you have to manage the whole codebase one feature at a time, but what we do is we can use branching and different feature branches. Each one of us is working on their own feature branch. We collaborate, we merge our changes, and we can roll back in case we introduced some bugs. I would say the version control feature is a huge bonus or a huge plus.

We are still experimenting with testing, but not that much. We are not using some features yet. We are trying to introduce them because we are coming from a background of SSIS. The team used to work with SSIS, Microsoft SQL Server Integration Services. We are still adapting one feature at a time. Currently, we are working with the SQL modules and with the Jinja templating. We are experimenting with testing, but I would say towards the end of this year, we are planning to explore more of the documentation and the data lineage options as well.

I would say the benefits are coming from GUI-based tools like SSIS. We have more control on the codebase. We can create something of a system where we can use macros and templating, speeding up the development cycle. We are now trying to introduce a little testing, and also we are using some sort of a CI/CD cycle, so continuous integration and continuous deployment. I do not believe that these kinds of features are that common as a package as a whole package. dbt excels in that area.

I used to have a couple of notes about the performance, but lately I have discovered something called dbt Fusion, which, according to dbt Labs, they proclaim is much faster during the parsing of dbt models. However, I would love to see even more of an out-of-the-box solution regarding the testing. They are treating the testing in a good way so far, but I would love to see even more improvement because the whole data testing field is not very mature. It is not the same as software testing; for example, you have test suites, test tools, and profilers, but for data testing, it is not yet that advanced. I would love for dbt to take the lead on that.

I have been using dbt since September 2024, so almost a year and a half.

I think that one of the issues with dbt is upgrading to later versions because we have some functionalities that we have designed that overcome default behaviors for dbt. Every upgrade is a little bit of a risk for us because we do not know if the workarounds that we developed will be available for the next version. However, in terms of stability, we have had no issue.

I would say we have not experienced scalability issues so far. I am not aware of the scalability, but we are managing it on a very large scale. The bottlenecks that we have are not coming from dbt; they are coming from Snowflake. Once we scale up Snowflake, dbt has no issue whatsoever.

Besides the issue with the upgrades and the default behaviors for the macros that we overwrote, we did not really need to reach out to dbt support.

The team used to work with SSIS before I joined. They used to work with it, I believe, two or three years ago, but since I joined a year and a half ago, they switched to dbt. They switched to dbt just before I joined. I have also worked for some time with Apache NiFi as well.

I am not aware of the initial setup because they set up everything before I joined, but they are using dbt Cloud. I do not think there are many difficulties or any hurdles to overcome during setup. You simply link your dbt Cloud account with the Snowflake account and that is it.

In terms of metrics, I do not have exact metrics, but I get a sense of the speed of opening and closing data requests. I am not that familiar with the Scrum Master of our squad, but I believe our burn chart or something like that, which is an agile metric that measures the finished user stories, is the only sense or only kind of metrics that we have at the moment. However, you do get a sense of accomplishment and the speed of delivering value.

I would say just the testing is something to focus on. dbt Fusion is something I am not completely aware of, but I need to try it because I think it is a great feature, especially because we are dealing with multiple models. For our use case, we are dealing with 50 plus, almost 100 models. Many models are running at the same time. If you add up all the compile time and parsing time, it can add up to quite a bit. dbt Fusion promises that the parsing is much faster in one-tenth of the time, I believe.

I would say you really need to take care of your model and your data model because dbt gives you some freedom. If you do not really know what you are going to do, you can really mess things up. So you need to take care of the model, design your layers, define the responsibilities of each layer, define the criteria of each data layer, define the tests, and that is it.

I would rate this product an eight out of ten.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

I have primarily used dbt for data transformation. My team and I work with source systems from various clients, some using Snowflake, others using SQL Server, and some using their own legacy source systems. We extract and load all the data into our data lake on Azure. From there, we use dbt to transform that data. In technical terms, we have extracted and loaded the data into our data lake, and from there we are doing the transformation with dbt. We are creating different layers such as silver, bronze, and gold to build a medallion architecture with dbt.

From a developer point of view, I find the ease of development and the code to be the most useful capabilities of dbt. I use VS Code to run the dbt models, and since the end user is only concerned about their output and reports, the ease of development and the fact that it is free are significant advantages.

I assess the impact of dbt's version control system on team collaboration as great. I have used it extensively, especially when we had situations where the code broke, as we were able to roll back to earlier versions thanks to version control.

I find dbt's documentation site generator to be quite crisp and straightforward. It helps with project transparency and onboarding new team members because the documentation is excellent for addressing issues we face. I learned dbt concepts primarily using their website and their tutorials, which helped me significantly compared to other platforms such as YouTube and Udemy. The course content that dbt provides is free and excellent for anyone starting out.

dbt seems quite adequate currently, but if I needed to name a few areas for improvement, I would mention the migration of code to Git and GitHub, which sometimes fails and can be confusing for developers during handover. There are some glitches in the connection, but I am unsure if that is an issue from the dbt side or something else, so I cannot comment definitively.

I have been working with dbt for approximately seven to eight months.

Regarding stability and reliability, I see the tool as quite good. In terms of use case, market presence, demand, learning, and performance, I believe dbt will continue to be in the market.

I would rate dbt's stability and reliability at a minimum of eight out of ten based on the limited experience I have. Comparing it to tools I have seen in the past, such as Informatica and Alteryx, dbt can easily match up to that rating, specifically for stability.

I am not very certain how scalable dbt is from my experience, as I have had limited scope to work with it. I have not analyzed it deeply. I started as a developer and began with their free plan before moving to a paid plan, which was quite affordable at around one hundred or one hundred fifty dollars per month. We are currently focusing on report development and multi-tenant deployment, so we might consider scaling in the future.

Earlier, we used technical support for dbt, but that was only valid for a month or fifteen days. We later moved to the paid version because I was working on the proof of concept of Qlik Sense and other tools, and we finalized dbt as well. Initially, I explored dbt for free for about ten days without trialing any further support.

So far, we have not interacted much with technical support because we usually get help from the community on their website. If you type your question, you will likely find that someone has already asked it, so we do not need to contact their support directly.

Positive

I have not yet utilized dbt's testing framework.

My experience with the initial setup and deployment of dbt involved using VS Code. I am not very confident here because I received some help from another data engineer to set it up on my machine. However, I have used VS Code in the past, and with some libraries, it was successfully done, but I am not entirely certain about every detail.

I am both a customer and consultant for dbt because my company has bought the license, and as an experienced person, I work on a product for my company.

The course content that dbt provides is free and excellent for anyone starting out.

I have not practically used a different solution for the same use cases, but I have been part of teams that used tools such as Alteryx, Informatica, and Talend, even though I did not work with them hands-on.

From a developer point of view, I find the ease of development and the code to be the most useful capabilities of dbt. I use VS Code to run the dbt models, and since the end user is only concerned about their output and reports, the ease of development and the fact that it is free are significant advantages.

I assess the impact of dbt's version control system on team collaboration as great. I have used it extensively, especially when we had situations where the code broke, as we were able to roll back to earlier versions thanks to version control.

I find dbt's documentation site generator to be quite crisp and straightforward. It helps with project transparency and onboarding new team members because the documentation is excellent for addressing issues we face. I learned dbt concepts primarily using their website and their tutorials, which helped me significantly compared to other platforms such as YouTube and Udemy. The course content that dbt provides is free and excellent for anyone starting out.

dbt seems quite adequate currently, but if I needed to name a few areas for improvement, I would mention the migration of code to Git and GitHub, which sometimes fails and can be confusing for developers during handover. There are some glitches in the connection, but I am unsure if that is an issue from the dbt side or something else, so I cannot comment definitively.

I would rate my overall experience with dbt at eight out of ten.

I am currently working with dbt and Snowflake together. We use dbt for data transformation purposes. We obtain the data and store the raw data directly into Snowflake, then perform all transformations using dbt to prepare the data for reporting purposes.

We use dbt's modular SQL models. In dbt, we do not use full refresh or full data refresh. We have incremental strategies in place that only compute or transform incremental data, which operates in a CDC architecture. This approach is very fast, and we use it on a daily basis. We have scheduled all our dbt models using Airflow to run according to the scheduled time.

We use dbt's testing framework and the inbuilt functionality of dbt testing. For example, we use dbt's built-in tests to identify not null values and determine how many not null columns and values exist in each column. Beyond the built-in functionality, we have written custom SQL scripts to create external test cases on our models.

We ensure that incorrect or incomplete data does not go into the reporting layer because it can impact the business. We always perform dbt tests on our landing or raw data to ensure the correctness and completeness of the data before loading it into the final reporting layer. These reports are used by higher management, so we ensure that incorrect data is not published into the reporting layer for the Power BI reports.

We use dbt's documentation site generator. In dbt, we have YML file functionality, which can be used for creating documentation for each model. Whenever we make modifications to a model, we always update the YML file so we can track the history of how frequently we change the model. When new team members join, they can refer to this documentation to understand the data lineage and the data transformation strategy of the project.

dbt is very fast compared to the traditional tools. Previously, I worked on SSIS, which is provided by Microsoft, and data transformation took a considerable amount of time when dealing with large amounts of data. Since dbt works on the ELT architecture rather than the ETL architecture, it is much faster than traditional data transformation tools.

Previously, we were using SSIS packages, which were very slow. Recently we migrated all our SSIS packages to dbt models. After the migration, we moved the data from SQL Server to Snowflake. Previously, our data pipeline took around two days to load complete data when performing a full refresh. Since we migrated from SSIS to dbt model architecture, it takes around four hours only to complete a full refresh. The client is now happy because our downtime was drastically reduced when we perform a complete refresh of the data.

I am not very familiar with dbt's version control system.

I cannot identify any improvements in dbt because I am still exploring more functionality. I have been working with dbt for only three years, so I am exploring more functionalities and cannot see any limitations or improvement areas at this time.

In the past, I used the seed functionality, which is used to load raw files, individual files, or static files into the database. Going forward, if dbt can improve or implement more features on the seed side, that would be beneficial, especially when we have large files available that take time to load the data into Snowflake database.

I have been working with dbt for the last three years.

I have not experienced any crashes, performance issues, or anything regarding stability and reliability.

I find dbt very scalable.

The dbt support team is very responsive. Whenever we have any issues on the dbt side, we always reach out to them. We did not face any challenges in the initial setup. I would rate the technical support a nine out of ten.

Positive

Previously, we were using SSIS packages, which were very slow. Recently we migrated all our SSIS packages to dbt models. After the migration, we moved the data from SQL Server to Snowflake. Previously, our data pipeline took around two days to load complete data when performing a full refresh. Since we migrated from SSIS to dbt model architecture, it takes around four hours only to complete a full refresh. The client is now happy because our downtime was drastically reduced when we perform a complete refresh of the data.

The main reason we decided to switch to dbt is performance. As mentioned earlier, every quarter we perform a full refresh, and that refresh took considerable time on SQL Server. Since we had to migrate because our data is very large and growing daily, we adopted dbt because Snowflake is very fast. In Snowflake, the storage layer and the computation layer are separate, which is not present in the SQL Server traditional database. That is why we moved from SQL Server to Snowflake and from SSIS to dbt.

We evaluated Databricks as well, but ultimately the client wanted to adopt Snowflake and dbt technologies only.

We took help from Snowflake directly, the Snowflake company, for the Snowflake side. The dbt side is maintained or set up by our infrastructure team.

Since we migrated from SSIS to dbt model architecture, it takes around four hours only to complete a full refresh. The client is now happy because our downtime was drastically reduced when we perform a complete refresh of the data.

The pricing, setup cost, and licensing cost are managed by our infrastructure teams. As data engineers, we are not familiar with these details.

I need to check with my infrastructure team on whether we purchased dbt through the AWS Marketplace or directly from the local vendor.

Since dbt has a license cost, if a company is small and does not have much budget, they can explore other tools because there are other tools that provide the same functionality at a lower cost. If an organization is small, they can explore other products as well.

I am currently working with Power BI, Tableau, Python, Databricks, Snowflake, and PySpark in the current project. I would rate my overall experience with dbt a nine out of ten.

dbt is used for data transformation and data engineering with multiple data transformations and engineering functions. It is also used for orchestrating data engineering pipelines. An example of this is ingesting data from Azure Blob or S3 sources and then transforming it into different layers in the data platform.

The best features of dbt include lineage and Jinja templating languages that make it easy for creating pipelines.

The built-in lineage feature provides a good understanding of the several layers where data is being loaded in dbt, allowing visibility from different layers into the end product.

dbt has positively impacted version controlling as it has different version control steps involved. The specific improvements seen with version control in dbt are that it has helped trace the data lineage, enabled faster trace and rollbacks, and enabled safe collaboration at every scale, which has improved data quality.

A return on investment has been seen from using dbt as the time has reduced while utilizing dbt in the form of data pipelines and ETL scripting. There is operational efficiency achieved, and data quality and governance have also been achieved with modular SQL and version controlling, which reduced duplication of data and data errors.

dbt is not as stable as preferred, as it has had a few outages in the current year itself, so improvement should be made in the outages section as it is not stable.

The copilot in dbt is not very comfortable for users, and my team has already tried using it but opted to move off from the dbt copilot to other copilots such as GitHub.

Improvement is needed in the tool itself in terms of the copilot, in terms of covering outages, in terms of testing, and in terms of quality reasons related to governance and collaboration.

dbt has been used for about a year.

dbt is not as stable as preferred, as it has had a few outages in the current year itself, so improvement should be made in the outages section. Overall, dbt is stable.

In terms of scalability, dbt has improved the scalability of the organization depending on different dimensions for team size, data, and complexity of transformations.

The customer support from dbt was good and was identified and resolved by the customer support team when reached out to.

Neutral

Initially, multiple solutions such as Talend Studio and Informatica were utilized for different projects before switching to dbt.

The experience with pricing, setup cost, and licensing was that it was straightforward for the pricing setup and also on the licensing part for dbt.

A return on investment has been seen from using dbt as the time has reduced while utilizing dbt in the form of data pipelines and ETL scripting. There is operational efficiency achieved, and data quality and governance have also been achieved with modular SQL and version controlling, which reduced duplication of data and data errors.

dbt was purchased through the AWS Marketplace.

Before choosing dbt, other options were evaluated, but dbt was the preferred choice as it was an open-source solution that was already on the track.

My advice to others looking into using dbt is that it is a good tool for having ETL or ELT transformations done. To begin with, a pilot project can be added with modular SQL or modeling, Git workflows, and a standardized project structure from source, staging, intermediate, to the mart layers, which will optimize performance. I would rate this solution a seven out of ten.

A specific example of how I use dbt for data transformation and engineering is that we use it to connect and ingest data from our Azure blob and S3 buckets, then transform through our glorified serving layers into our data platform.

We use dbt to orchestrate our data engineering pipelines.

The built-in lineage feature and the Jinja templating have made things easier for me because it's an easy language that most people pick up pretty quickly, and the ability to template SQL and generate SQL programmatically is useful.

dbt has positively impacted my organization by allowing us to create our data pipelines much faster, going from ingestion of data to creating a data product in weeks instead of months, and we can do it in-house with the skillset we already have.

I can share a specific outcome that resulted from using dbt: there was a data product a vendor did for us two years ago that took them six months to achieve, whereas we were able to do it in-house with dbt coupled with Snowflake in four to five weeks, which was much quicker.

dbt is not as stable as I would prefer, as there have been a few outages this year.

My advice for others looking into using dbt is that it is good if you have an organization with engineers who prefer to code and get hands-on, but if you have teams of engineers who prefer a mouse-driven, drag-and-drop type, less technical coding environment, other tools might be more appropriate.

I rate dbt overall an eight out of ten.

My main use case for dbt is data pipelines. I build data transformations and usually construct analytics pipelines.

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.

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.

I have been using dbt for four years.

dbt is stable.

dbt's scalability is probably where it shines the most; it is really scalable compared to using just SQL.

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.

I did not previously use a different solution before dbt; every time I have used dbt, it was always embedded.

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.

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.

I did not evaluate other options before choosing dbt.

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.

I am currently working with dbt and use dbt's modular SQL models.

It is very convenient because at the end, I have the opportunity to orchestrate all my transformations in just one single place, rather than having them spread out. I can use SQL, which is very convenient for the sizes of data that I usually use in the day-to-day. Of course, some other deployments might require Spark, and in this case, it is not a good idea to use SQL plus dbt, but for most cases, it is very convenient. Because it is easy to set up, and also due to the cost, I have all the transformations in one single place with a very convenient tool.

It is very convenient; I can set up the expectations really easily, all integrated in the tool that I usually use for my data transformation, so it is very convenient.

With AI, everything is advancing so fast, so I would say that the most important thing is to try to integrate with more platforms. As of now, dbt has a strong integration with AWS and with Snowflake, but I have not seen other integrations. Having more partners and having more visibility on the things that can be done is important, because I see that competitors are doing great in that aspect. For example, Databricks and Snowflake itself are doing that, so more visibility, more partnerships, and more integrations would be helpful.

I have been using dbt for five years as of now.

I may not have enough information to respond about the technical support of dbt because I have not reached out to dbt support at any time, probably because I have never needed it. In the three or four organizations that I have been with using dbt, I have not contacted the support service directly, so it may be a good sign.

I will say the deployment for dbt is very straightforward; once you have the experience, it is quite straightforward. For example, you can set up a Docker or Docker Compose and run it, or you can use directly the on-cloud version.

I would say that the deployment for dbt requires about a day; a day could work, and with a day, you can set up and deploy dbt.

I find that with one person, it is enough to complete the deployment; of course, it can vary depending on the complexity of the project, but I would say that one person working one day is enough.

I mentioned the cost as one of the advantages, specifically the license cost.

I think the pricing is very convenient; one of the barriers is that for example, some of the companies that I have been with, dbt is a normal solution or neutral in terms of cost. It is not cheap or more expensive, but the problem is that companies are really locked in with existing vendors, and those vendors offer alternatives that might be less expensive given that they have other products. dbt only offers data transformation services, making it hard to compete with vendors that have all the packages included, such as cloud and processing services. If you compare the cost of those packages with dbt alone, it is more expensive to use dbt alone.

I am using a private cloud. I have used both on-prem and cloud versions of the product, but mainly the managed version, the on-cloud version. That is very convenient; of course with AI, that is being commoditized a little bit. But I like it; I used it more before. Now with AI, it is even easier to do documentation, but before AI, it was really convenient to generate documentation with that tool. My overall review rating for dbt is 7 out of 10.

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.