The Las Vegas Strip and accompanying events aren’t often described as subtle, but the Community Keynote at dbt Summit 26 quietly guided attendees on a journey towards what the future of data infrastructure might entail.
Throughout, Grace Goheen and Jeremy Cohen, with the help of some external speakers, walked the audience through what becomes possible once you unlock and invest in the open-source capabilities that can integrate with dbt: open storage with Apache Iceberg, lightning fast platform connectivity with Apache Arrow through ADBC connections that ship with dbt v2. Performant and structured dbt metadata with the new parquet artifacts that ship with dbt v2 and documentation rebuilt from the ground up. All of the above pointed to a future of data transformation agnostic to platforms and conducive to multi-platform architecture - not locked in a particular UI.
One phrase kept surfacing, in the keynotes, the breakouts, the happy hours afterwards: ‘openness’.
Open Data, Open Standards, Open Future: the shift from Modern Data Stack (MDS) to Open Data Infrastructure (ODI)
The key takeaway from dbt Summit 26 for me, is this: the Modern Data Stack, possibly the most common or aspired to data stack implementation, needs a rework in the age of AI. Not the tools, most of them are still very much in use, but the framing. MDS always meant a warehouse at the centre, wrapped in effective tooling around it. The stack itself was often lean, just a handful of tools, and the knock-on effect of that leanness was a stack that stayed pretty platform-centric by default.
Open Data Infrastructure is a reframing and in some ways a hedging strategy for the future. The warehouse/platform is still a key component. But the framing has shifted: instead of a single dependency (or a single point of failure), you lean on open source tools, patterns and frameworks that increase malleability, substituting in newer, better tools where it makes sense, all on the same open foundations. At that foundation is an open table format like Apache Iceberg, a storage format that major compute players (Snowflake, Databricks, AWS etc.) are all integrating into their offering.
dbt’s product announcement of simplifying your iceberg journey is angled at further driving this uptake of open storage. Iceberg tables have historically been more maintenance heavy in terms of looking after the tables and ensuring they are performant. dbt’s stated goal is to strip away all the concerns and fear and make Iceberg accessible to all.
The dbt vision of simplified ‘Iceberg for all’ opens up a world of possibilities in a data mesh architecture where the finance domain might be on Databricks whilst the marketing team might be on Snowflake yet the data can be interchanged freely through dbt configurations to tell a platform how to access a catalog that contains Iceberg tables; whether that be a native catalog in a Snowflake -> Snowflake situation or an external catalog in the Snowflake -> Databricks situation. The strides in this space are further fuelled by another dbt product announcement: the bundling of connectors into dbt v2 and the use of Apache Arrow (Open Source) in ADBC connections to platforms for faster data transfer.
It is worth noting here dbt’s ideal product vision: Cloud Warehouse compute is highly effective but at times expensive and over-resourced for simple operations. This has led to dbt’s first foray into the compute space, enabled by its merger with Fivetran and historic ties to DuckDB. Lake Compute is dbt Fivetran’s DuckDB powered compute that can work on FiveTran Data Lake Service. The idea is that a company could ingest their data through Fivetran, land it in Data Lake Service as Iceberg tables and use this compute to perform simple operations on the data and save the warehouse for more complicated operations and therefore make cost savings. The cynic might point out that this is itself a shift towards a walled garden. Two counters: the vision is still underpinned by Iceberg, so the data stays widely accessible, and this was pitched as an option for cost savings, not a one-stop architecture everyone should adopt.
From ‘Role Clarity’ to ‘Role Consolidation’
At the Hex ‘Friends of Data’ Event that included an interview with Tristan Handy, I observed an interesting reflection from Tristan. Tristan and dbt Labs have long been associated with role clarity and the advent of the ‘Analytics Engineer’. Throughout the conference there was an increased narrative around ‘Context Engineering’ and adapting our work and practices to a reality where agents and AI are the primary consumers of data. Related to this was Tristan’s reflection at the Hex event that he sees us heading into an era of role consolidation around what he termed ‘Data Practitioners’. It was informed by the belief that the idea of Analytics Engineering and the use of the Analytics Development Lifecycle (ADLC) are now both settled. With the advent of AI there is less a need for specialists and more a need for people with a strong grasp of the foundations (read here ADLC) who can apply them to a range of data problems: building agents for conversational analytics, building agents for development, the more historic building of data products and building typical dashboards and reports but with an emphasis on doing so as code to leverage AI and align to the view of code first development.
Simplifying dbt Product Messaging
For over a year dbt has struggled with marketing their fusion engine amongst the platform, core offerings made a bit more confusing by the announcement of dbt Core V2. At Summit, dbt announced it was retiring the Fusion terminology and announced dbt V2. Now there is a tighter classification of offerings: dbt OSS - which maps over from dbt Core V2 it is the open source offering covered by the Apache 2.0 License. dbt OSS brings the faster parse and compile times from the rust engine, information schema, upgraded docs. It is primarily intended for people who want to fork the project and build out their own custom transformation tool.
Otherwise, it is recommended that you opt for dbt [V2] which maps over from Fusion. This unlocks some of the proprietary features like SQL comprehension, linting and language model. dbt State and Wizard are usage based add-ons, whilst dbt Mesh and Catalog are seat-based add-ons. dbt Platform represents the streamlined SaaS, hosted offering that as you might expect can run the updated dbt.
On the surface, a company simplifying its own naming isn't the flashiest of announcements. But in this case, it was a fairly pivotal update from a commercial perspective.
Building Effective Semantics to Enable Agentic Capabilities
The final theme worth unpacking is 'context engineering'. Nobody at Summit was arguing that semantics matter, that debate felt closed. What's actually being fought out now is how you organise, govern and structure your semantics and processes to unlock the capability everyone agrees is sitting there.
One line from a breakout has stuck with me: "humans compensate for bad context. Agents amplify it." A human analyst handed a vague build ticket will ask follow up questions. A human provided with a vague metric will rely on business logic or again ask for clarification. An agent won't. It will try its best to build a solution or find an answer with the resources it has, often resulting in a confidently incorrect result. So the organising work matters: semantics as code, specifications (the brief an agent is meant to build against) written at the right level of detail, evaluations (essentially tests, but for agent output rather than code) that test whether an agent's output actually holds up rather than just whether the code runs. And even then, best-in-class guardrails still won't fully close the door on hallucination, which is why the sharper teams are also building in a second line of defence, keeping agents boxed into the specific task and context they're meant to operate in, rather than trusting guardrails alone to catch a bad answer on the way out.
dbt's positioned itself squarely inside this fight rather than off to the side of it. Its backing of Apache Ossie (the semantic and ontology standard formerly known as Open Semantic Interchange, now incubating at the ASF alongside Snowflake, Salesforce, Databricks and others) is the clearest signal of where it's placing its bet: on organising semantics as a shared, open problem, not a proprietary one. Which loops back to the thing that kept surfacing all week. If you're co-authoring the open standard for how meaning travels between tools, you've committed to the opposite of a walled garden.
In a year with massive leaps in the AI space that have been unpredictable, businesses want to keep their options from a tooling perspective as open as ever to adapt to these changing circumstances. At dbt Summit, dbt presented itself as an ideal shepherd in this era.