DuckDB and Its Ecosystem
The DuckDB story now extends beyond the original database. Here is how the projects, organizations, and commercial services around it developed, and how they fit together today.
Q2 was a busy quarter. On May 12, the DuckDB team published a technical preview of Quack, the DuckDB client-server protocol. Quack extends DuckDB into networked deployments while preserving the in-process model that shaped the database from the beginning.
Two weeks later, on May 27, we announced that DuckDB Labs had become DuckLabs. The new name reflected a company whose work had expanded beyond DuckDB alone. It also marked the start of a more visible phase for DuckLabs, including more communication about the projects, the engineering team, and the organizations that work with them.
The two announcements concerned different parts of the technology, but both reflected a story that had been developing for years. With all these developments, we think it's time for an update on how we got to where we are today. The best place to begin is at the origin of DuckDB itself.
Hello world
Mark Raasveldt and Hannes Mühleisen began developing DuckDB in 2018 while working as database researchers at Centrum Wiskunde & Informatica (CWI) in Amsterdam. Their work grew from database systems research, later documented in papers on DuckDB's design and architecture, including its embedded analytical model.
DuckDB was open source from day one. In 2019, Mark and Hannes announced DuckDB v0.1 at the SIGMOD conference in Amsterdam. DuckDB could run as a single binary or inside Python, R, or another host process, giving users an analytical SQL engine without requiring them to deploy and maintain a separate database server.
This in-process architecture removed a familiar source of friction. Developers could query files and data where they were already working. Data scientists could bring SQL into a notebook without first deploying database infrastructure. Product teams could embed analytical processing directly in their applications.
As more people began using DuckDB, the project needed a permanent engineering home and a structure that could support long-term development.
The ecosystem begins to take shape
On July 14, 2021, Mark and Hannes announced DuckDB Labs as a CWI spin-off. The company brought the core engineering team together and created a commercial route for organizations that needed support or development work.
The independent DuckDB Foundation was incorporated later that year. It holds most of DuckDB's intellectual property and safeguards the project's continuity under the permissive MIT license.
The company and Foundation were designed for different responsibilities. DuckDB Labs became the engineering and commercial home of the core team. The Foundation provided the legal structure around intellectual property, trademarks, and long-term open-source continuity. Day-to-day development remained with the engineers and contributors working on the project.
MotherDuck adds a managed cloud path
DuckDB's local and embedded model covered a wide range of analytical work. Some teams also wanted centralized storage, sharing, collaboration, access control, and managed operations. MotherDuck was formed to build that cloud experience on DuckDB. In November 2022, DuckDB Labs announced a long-term partnership with MotherDuck.
MotherDuck contracts with DuckLabs for engineering work, supports the DuckDB Foundation, and contributes technology to the wider project. DuckLabs gives MotherDuck direct access to the people developing and maintaining the database.
The partnership works through clearly defined roles. MotherDuck operates the managed cloud service, the Foundation holds DuckDB's intellectual property, and DuckLabs leads core engineering and commercial support around the open-source projects. The companies collaborate where their technical work overlaps.
DuckDB reaches 1.0
On June 3, 2024, the team released DuckDB 1.0.0.
The release emphasized stability rather than a long list of new features. DuckDB had gained backward compatibility for its storage format, extensive testing across the engine, and a more cautious approach to changes in the SQL dialect and C API. Version 1.0 expressed the team's confidence that developers could build applications on DuckDB with clearer expectations about compatibility over time.
It was also a marker of adoption. Six years after the first code was written, DuckDB had moved from a research project into production systems, data workflows, and embedded products across a growing community.
Later that year, MotherDuck made significant contributions to the new DuckDB Node.js client, another example of technical work shared across the ecosystem.
The work expands beyond the original database
In March 2025, DuckLabs and MotherDuck introduced the DuckDB Local UI, a browser-based interface delivered through the DuckDB ui extension. It runs queries against a local DuckDB instance and provides an explicit path to connect to MotherDuck when users want cloud capabilities. The project showed how the two companies could combine local and managed experiences in one workflow.
Two months later, the DuckLabs team introduced DuckLake, an open lakehouse format that keeps catalog metadata in a SQL database while storing data in the open Parquet format.
DuckLake applied the team's database engineering experience to a different layer of the data stack. The work now covered the analytical engine and the organization of shared lakehouse data. The name DuckDB Labs was beginning to describe only part of what the company maintained.
The broader direction becomes explicit
DuckLake reached version 1.0 on April 13, 2026, establishing a production-ready specification and reference implementation.
The Quack technical preview followed in May. Quack is the DuckDB client-server protocol, designed for workloads that need remote connections or multiple clients. It is available as a beta release while the team develops it toward stable status as DuckDB v2.0.
The change from DuckDB Labs to DuckLabs came later that month. By then, the company employed more than 30 people working across DuckDB, DuckLake, Quack, extensions, language bindings, and related systems engineering.
DuckLabs' commercial role is important. Organizations can engage the company for enterprise support, feature prioritization and development, technical advisory, and engineering collaboration. These services provide direct access to the team responsible for the projects. When customer requirements belong in the open-source core, the work can be reviewed, integrated, and maintained with the rest of the project.
How the pieces fit together today
At the center is DuckDB, the open-source analytical database. DuckLabs was created by DuckDB's original co-creators and employs the core contributors who develop DuckDB and related projects. The DuckDB Foundation holds the intellectual property and protects the projects' open-source continuity.
DuckLake extends the team's work into an open lakehouse format. Quack is the DuckDB client-server protocol, currently available as a technical preview. MotherDuck operates a managed cloud service built on DuckDB, supports the Foundation, and contributes engineering to the wider project.
Several ways to run and support DuckDB
Users can now choose among several operating models.
DuckDB can run locally, inside a notebook, or embedded in an application. The Local UI adds a browser interface to a local instance. Quack introduces a self-hosted client-server option. DuckLabs provides support and direct engineering collaboration around the open-source projects. MotherDuck provides a managed cloud service for teams that want the provider to operate the cloud layer.
These options can serve different stages of the same project or different requirements across an organization. Their common technical foundation allows the DuckDB community to grow without prescribing a single deployment path.
What lies ahead
DuckLabs is entering a more visible phase, although its engineering role has been established for years. DuckDB v1.0 marked the maturity of the original database. DuckLake and Quack now show how the team's work is expanding around it.
Future posts will continue to explore these and other projects, the ways organizations use them, and how enterprise support and feature development contribute to the continued evolution of DuckDB.