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.

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 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.