The first useful thing to know about dbt is that it does not move data. It does not own the warehouse where the data lives. It arrived after both of those decisions, in the awkward middle where a company has collected plenty of numbers but cannot get two departments to agree on what any of them mean. An analyst writes a SQL query. Someone copies it. A dashboard adds a hidden filter. By Friday, “revenue” has three definitions and the person who remembers why is on vacation.
dbt Labs built a business by treating that mundane mess as an engineering problem. Its original open-source tool, dbt Core, lets analysts turn SQL queries into modular models, connect them through explicit dependencies, test the results, document the logic and review changes in Git. The database still does the computation. dbt organizes the thinking. That distinction sounds small, but it gave a generation of analysts the working habits software developers had taken for granted.
A job title hiding inside a command line
dbt began in 2016 at Fishtown Analytics, the Philadelphia consultancy founded by Tristan Handy with Drew Banin and Connor McArthur. The name came from the neighborhood where Handy and his wife discussed whether he could afford to try something new. The early company paid its bills with consulting. dbt was the internal tool that made the work repeatable, then the open-source project clients kept wanting.
The founders’ sharper insight was social, not technical. Cloud warehouses had made storage and compute easier to buy. SQL-capable analysts understood the business but were trapped in brittle workflows. Data engineers understood production systems but could not personally encode every marketing, finance and product rule. Between them sat a missing role. dbt Labs helped name it “analytics engineering” and supplied its kit: models, tests, documentation, lineage and code review.
The product spread because it made analysts more independent without pretending they were working alone.dbt’s community logic, in one sentence
Early adoption traveled person to person. Casper was an important first customer. Practitioners carried dbt into later jobs; consultants made it standard in client stacks; local meetups and a Slack community turned implementation details into a shared craft. The company says more than 100,000 teams now use dbt weekly. Its public GitHub organization holds hundreds of repositories, while dbt Core itself has attracted thousands of stars and contributors. The community was not decoration around the product. It was the distribution mechanism.
What customers are actually buying
The free framework is the front door. The commercial dbt platform - previously marketed as dbt Cloud - sells the things that become difficult when a project grows from one enthusiast to a regulated enterprise: managed development environments, job scheduling, continuous integration, access controls, audit logs, deployment, alerts, cataloging, lineage, shared metrics and support. A free Developer plan serves one person. The public Starter plan is $100 per user each month. Enterprise and Enterprise+ are custom-priced, with more projects, security controls and service commitments. Newer dbt State features add a usage-based component.
Different products handle different pieces of that burden. dbt Catalog maps metadata, documentation, health and column-level lineage. dbt Mesh lets large companies split ownership among domains without giving up contracts and discoverability. The Semantic Layer, powered by MetricFlow, defines a measure once and computes it consistently for every connected tool. Canvas gives analysts a visual route into transformation. Insights supports governed exploration. Orchestrator and State decide what work needs to run. Copilot and Wizard bring AI into development, while an MCP server offers dbt’s context to outside agents.
The customer is usually a data practitioner, but the economic buyer is often a data or technology leader who wants faster delivery without a free-for-all. JetBlue’s case is instructive. Its central team moved 26 data sources and 1,200 models to dbt in three months, while holding total cost of ownership flat. The deeper problem was organizational: airline definitions are full of edge cases, and a central team could not own every one. Versioned code, tests and distributed contributions let domain experts participate without abandoning review or compliance.
The moat is a file format with friends
dbt competes in several markets because its product has expanded in several directions. SQLMesh and Google’s Dataform challenge code-first transformation. Coalesce and Matillion offer visual or managed pipeline development. Airflow, Dagster and Prefect overlap in orchestration. Monte Carlo watches data reliability; Atlan and Collibra organize catalog and governance. Snowflake, Databricks, Microsoft and Google increasingly build native versions of the workflow into their own platforms.
dbt’s difference is less a feature checklist than a portable convention. A dbt project expresses models, dependencies, tests, documentation and metrics in familiar files. It can target Snowflake, Databricks, BigQuery, Redshift, Microsoft Fabric and other engines. Packages and adapters extend it. Practitioners recognize the structure when they change employers. Partners can build around the metadata. In a market where the underlying cloud vendors prefer customers to stay put, dbt’s cross-platform posture gives it a useful neutrality.
That neutrality is not pure. The company must keep a broad open standard healthy while reserving enough value for its paid service. Users notice when useful capabilities land only in commercial tiers, and cloud vendors can subsidize competing features through larger contracts. dbt’s answer has been to draw the line around scale and coordination: keep the core workflow accessible, then charge for the managed experience, rich metadata, governance and enterprise controls. The line keeps moving, and the community keeps watching.
A merger of two verbs
In October 2025, dbt Labs and Fivetran announced an all-stock merger. It closed on June 1, 2026. The combined company initially operates as Fivetran + dbt Labs, with Fivetran co-founder George Fraser as CEO and Handy as President. No transaction value was disclosed. At announcement, the companies said they were approaching $600 million in combined annual recurring revenue and had well over 10,000 paying customers; after closing, they described a footprint reaching more than 100,000 data teams.
The industrial logic is unusually legible. Fivetran extracts and synchronizes data from operational systems. dbt transforms that data and records the rules that give it business meaning. The products have long been installed together. Joining them puts movement, transformation, metadata and eventual activation under one company, while the pair promises customers freedom to choose warehouses, engines, catalogs, BI tools and AI models.
Fivetran moves the facts. dbt explains what the facts mean. AI raises the cost of getting either part wrong.The merger thesis
The timing is about AI, but not in the usual chatbot sense. A language model can generate plausible SQL quickly. It cannot infer with confidence whether “active customer” excludes trials, which currency conversion finance approved or why a late-arriving order belongs to last month. Those definitions live in people, dashboards and code. dbt’s metadata, tests, lineage and Semantic Layer are an attempt to make that context machine-readable. Fivetran’s job is to keep the underlying data fresh. Together they want to be the trusted substrate beneath agents that query and act continuously.
The second rewrite
dbt itself is also changing underneath. The Fusion engine, unveiled in 2025, was rewritten in Rust and designed to understand SQL rather than merely pass it through. That enables faster parsing, live error detection, richer lineage and state-aware execution. In June 2026, the company made the Fusion runtime the Apache 2.0 foundation of dbt Core v2.0 alpha. Proprietary Fusion capabilities extend that base with deeper SQL comprehension and immediate development feedback.
This technical rewrite matters because warehouse bills grow when teams rebuild tables that did not need rebuilding. State can reuse unchanged nodes. A compiler that understands dialects can catch mistakes before a query hits expensive compute. The company says Fusion has parsed a 10,000-model project far faster than classic Core in its tests, and reported more than 4,500 projects running on Fusion by June 2026. The practical promise is a shorter loop between writing code and trusting the result.
It also creates risk. A merged company must integrate products without turning two famously complementary tools into a bundle customers did not request. dbt must reassure maintainers that “open” remains more than positioning. Enterprise buyers will compare an independent layer against rapidly improving warehouse-native tools. And AI agents, the new audience in every data pitch, still need to prove they can create enough value to justify another infrastructure cycle.
Where dbt fits now
dbt sits between storage and consumption, but its ambition is moving upward. It began by compiling SQL transformations. It now wants to coordinate development, deployment, discovery, governance, semantics and AI context. The market calls pieces of this DataOps, analytics engineering, a semantic layer or an analytics development lifecycle. dbt’s preferred post-merger phrase is “open data infrastructure.” The label matters less than the territory: the shared logic that turns copied data into an agreed version of the business.
The company’s culture helps explain why it reached for that territory. Its published values include “transparency always wins,” “work hard and go home,” contributing to the knowledge loop and creating value before capturing it. The language can sound unusually earnest for enterprise software. Yet it matches the company’s history: an internal tool given away, a profession taught in public and a business built after practitioners had already decided the workflow was useful.
That is the lesson worth stealing. dbt did not begin by asking how to own every layer of data infrastructure. It made one neglected group better at its work, gave the practice a name and let the people doing the job teach one another. The merger gives the company more surface area, more customers and more ways to lose that clarity. Its next decade depends on whether it can make data infrastructure feel as legible as that first small command-line tool did.