Amazon Web Services signed an agreement to acquire DuckLabs, the Amsterdam company employing the core team behind DuckDB. The transaction is expected to take effect in early September. More than 30 DuckLabs employees will move together into AWS, including DuckDB creators Hannes Mühleisen and Mark Raasveldt.[1][2]
DuckDB’s source code, trademarks, and other core intellectual property stay with the nonprofit DuckDB Foundation. DuckDB, DuckLake, Quack, and the rest of the open-source “Duck Stack” remain under the MIT license.[1][4] Amazon is buying the organization that supplies most of the project’s engineering labor and technical direction.
That division makes the deal worth examining. Open-source control lives in several places at once: copyright, trademarks, maintainer time, release authority, extension distribution, integration budgets, and the institutional power to turn a roadmap into working code.
A database designed to disappear into the process
DuckDB became popular by removing the usual database ceremony. It runs inside a host process, much like SQLite, and performs analytical queries directly over local files, data frames, object storage, and lakehouse formats. There is no separate database server to provision for the common case.[3][5]
That architecture shifted analytical work toward laptops, notebooks, applications, and small services. Developers can query Parquet files or a Pandas data frame without building a permanent warehouse first. The database scales down cleanly while retaining a vectorized analytical engine built for complex SQL.
AWS already had reasons to pull that engine closer. The companies began collaborating in 2024. Their work connected DuckDB with Amazon S3 Tables and SageMaker Lakehouse, placing an embedded local engine beside AWS’s managed storage and catalog systems.[1][3] AWS says the acquisition will make its analytics products faster, simpler, and cheaper while giving the DuckLabs team more infrastructure and reach.[2][3]
This creates a useful distribution path. A developer can begin with DuckDB on one machine, keep data in Parquet or Iceberg, and later encounter AWS services built around the same engine and formats. The local tool becomes an on-ramp to cloud storage without requiring an explicit database migration at the first step.
The foundation now has to become operational
The DuckDB Foundation already owns the core intellectual property and trademarks. Its public structure currently names a three-person board: Mühleisen, Raasveldt, and CWI database researcher Peter Boncz.[4] Two of those directors will work for Amazon after the acquisition.
The founders have acknowledged the resulting governance pressure. They plan to add a technical advisory board so major users and community members can influence technical direction. They also plan to open the extension stack so extensions signed by other developers and organizations can run in DuckDB.[1]
Those commitments identify the real control surfaces. A permissive license protects the right to fork and redistribute code. It does not allocate maintainer attention, cloud testing, release engineering, security response, documentation, compatibility work, or integration budgets. A foundation becomes effective when it can fund those functions, set transparent rules, and exercise authority before a conflict reaches the repository.
The extension plan matters for the same reason. Database extensions sit close to files, credentials, network services, and executable code. Signature policy decides which publishers receive a smooth installation path and which ones require users to cross an explicit trust boundary. Opening that machinery to multiple signers can make DuckDB a broader platform. The governance details will decide whether it becomes a real commons or a curated marketplace with one dominant sponsor.
Mühleisen told The Register that the foundation’s exact governance and voting rights remain undecided. He described the proposed advisory board as a channel for organizations building on DuckDB, including companies whose products span competing clouds.[5] That unfinished design is the sharp edge of the acquisition.
AWS can behave generously and still become the gravitational center. It can hire more database engineers, pay for fuzzing and continuous integration, improve S3 and Iceberg performance, sponsor conferences, ship managed products, and expose DuckDB to millions of customers. Each contribution makes the project stronger. Each contribution also raises the cost of disagreeing with the sponsor that can implement a feature fastest.
An open license cannot fund a competing roadmap
The MIT license gives any company broad permission to use, modify, and sell DuckDB. MotherDuck, Fivetran, Google, Microsoft, independent vendors, and individual developers retain that legal freedom. The Foundation’s ownership of trademarks and project IP prevents AWS from simply converting upstream DuckDB into proprietary code.[1][4]
A viable fork still needs people. Database engines carry years of performance assumptions, storage semantics, optimizer behavior, extension interfaces, and compatibility traps. The right to fork is strongest when governance prevents the split from becoming necessary. Otherwise, the community receives a legal exit with an enormous engineering bill attached.
DuckLabs was built to solve that labor problem. The founders rejected venture capital and kept the company owned by its founders and development team. Commercial contracts funded prioritized features while the company maintained the open project.[1] AWS now absorbs that financing model into a much larger platform whose incentives include S3, Redshift, Athena, Glue, SageMaker, and Iceberg services.[3]
The transaction price was not disclosed.[2][5] The strategic value is visible without it. DuckDB is becoming a standard query engine for data that lives outside a traditional database server. Owning the main engineering organization gives AWS influence at the point where local analytics meets object storage, open table formats, and managed cloud catalogs.
Amazon does not need exclusive ownership of DuckDB to benefit. It needs DuckDB to work exceptionally well with AWS infrastructure, reach AWS customers early, and keep the maintainers inside its planning cycle. Competitors can receive support too. AWS controls how much of its own money and engineering time reaches each path.
Independence needs measurable machinery
The founders say the team will continue working on DuckDB, DuckLake, Quack, and the broader community from Amsterdam. They also say AWS supports a stronger foundation, third-party extension signing, and continued vendor neutrality.[1] Those are concrete promises with unfinished implementation.
The next useful disclosures are structural. The foundation should publish board expansion rules, conflict-of-interest procedures, technical-advisory membership, voting rights, release and trademark authority, extension-signer criteria, security-response ownership, and funding sources. It should also show which project infrastructure can operate independently of Amazon accounts, employees, and budgets.
None of this requires treating AWS as a cartoon villain. Mature governance assumes incentives can diverge even when every person involved acts in good faith. Amazon will optimize AWS. DuckDB’s ecosystem includes users and vendors whose best outcome may route computation, data, and money elsewhere.
DuckDB’s code remains portable because the license says so. Its future direction will remain portable only if the institution around the code can disagree, fund work, approve publishers, and ship releases without asking one employer for permission.
Sources
[1] DuckLabs: DuckLabs to Join AWS, Projects to Remain Open Source [2] About Amazon: AWS to acquire DuckLabs [3] AWS Big Data Blog: AWS and DuckLabs [4] DuckDB Foundation [5] The Register: AWS buys DuckLabs