If you are following the news coming from DuckDB, most likely your feed has been “quacking” lately. On May 12th 2026, the folks at DuckDB labs had a major announcement: now it is possible for DuckDB instances to speak to each other. The protocol is appropriately called, you guessed it, quack.
At this point, a small confession. I welcomed all the excitement around quack, however I was struggling to understand what impact it would have on my own work. I went back and forth on my current workflow trying to identify use cases. I did find some small optimizations, but nothing that would match all that excitement in my timeline.
And, then, in one of those episodes where the answer had been in front of you the whole time but you failed to realize it, I had my aha moment: our dbt workflow. Quack is the missing piece DuckDB needed to make dbt team workflows work.
Let me explain. So far, DuckDB was great at what it promised. It was a super optimized analytics warehouse that you can run on your machine. Meanwhile, dbt is now the de facto tool most data teams use to transform their raw data in meaningful models. Your DuckDB + dbt combo workflow normally involves reading data from some cloud storage provider (like s3) and performing all the transformations on your local machine.
While this worked very well when developing in isolation, things got complicated quite quickly the moment you wanted to work in a more collaborative setup. Let me clarify this with an example.
Let’s say Ana is currently working on a new customer churn model. dbt and DuckDB means that she can work in a very isolated way and run all the models on her machine. That’s great. The problem starts when, let’s say her colleague Alex, wants to inspect Ana’s model, to validate her calculations. The complete development isolation had one considerable tradeoff: no simple way to share Ana’s work. Alex would have to ask for her file.
This is exactly what quack changes. It allows DuckDB instances to talk to each other. For dbt, this means that now Ana can run her models in a common DuckDB database shared by the team. If Alex needs to check Ana’s work, he can simply, for example, check dev.ana.customer_churn. In other words, quack has opened the possibility for dbt development flows that are more collaborative and akin to the experience developers have when working with other warehouses, like snowflake or BigQuery with possibly one big twist.
Unlike traditional warehouses, with dbt + DuckDB + quack developers can use their local machines to do the transformations and then write those changes to the shared DuckDB instance when ready. This also has a meaningful cost implication: computation happens on the developer’s own machine, not on a cloud warehouse billing by computation time. Compared to running every dbt model against Snowflake or BigQuery, the savings can be significant.
If you are a data team running on a small budget, this could be the stack you were looking for. Spin up a small shared DuckDB instance, configure your dbt targets, and you are good to go. Additionally, developers can take advantage of their local machines to build their models, something a traditional cloud warehouse simply doesn’t allow. Just keep in mind, quack is still in its initial stages and under development. However, the promise is there: your dbt development will soon get quacking and cheaper.