AWS acquires DuckLabs, the company behind DuckDB, and keeps the project MIT-licensed under independent governance
Announced on August 26, 2026 and confirmed in the August 31 AWS weekly roundup, the acquisition of DuckLabs by AWS brings the DuckDB maker in as a subsidiary, without touching the MIT license or the DuckDB Foundation governance. For data teams, DuckDB remains a safe bet; the open question is whether the server-side roadmap tilts toward AWS.
August 26, 2026. Mark Raasveldt and Hannes Mühleisen, the co-creators of DuckDB, announced on the official blog that DuckLabs will join Amazon Web Services as a subsidiary, effective early September. August 31, 2026. AWS’s weekly roundup confirmed the definitive agreement and led its selection with the news. The question is not “how much” — the figure was not disclosed — but “under what terms”: will DuckDB stay an open project, or follow the restrictive-license path other open-source databases took when hyperscalers came knocking?
The answer in one sentence: MIT, irrevocably
DuckLabs’s answer is unambiguous. DuckDB, DuckLake, Quack, and all the extensions “will remain free and open source software under the MIT license, under the stewardship of the non-profit DuckDB Foundation.” The foundation holds the projects’ intellectual property and trademarks, and the MIT license is irrevocable.
That construction is a deliberate choice. Where Elastic, MongoDB, and Redis responded to cloud-provider pressure by narrowing their licenses (SSPL, AGPL, RSAL), DuckLabs inverts the logic: the vendor joins a hyperscaler, but the asset stays in an independent foundation with public statutes. The Stichting DuckDB Foundation, incorporated in the Netherlands, holds the copyright and trademarks, governed by a three-person board of database researchers: Hannes Mühleisen (chair), Mark Raasveldt, and Peter Boncz.
What DuckDB brings to AWS
To see the appeal for AWS, you have to grasp what DuckDB is: an embedded analytical database that runs in-process, queries Parquet, CSV, and JSON files directly with SQL, and has passed 40,000 stars on GitHub. It is an OLAP engine you drop into a notebook, a pipeline, or an application, with no server to manage.
Two lines show the product’s power. Reading a Parquet file and aggregating it:
SELECT category, sum(amount) AS total
FROM read_parquet('s3://bucket/transactions.parquet')
GROUP BY category
ORDER BY total DESC;That “lightweight, serverless analytics” positioning fills the gap where Redshift and Athena are overkill: local analysis, ad hoc queries over files, and eventually native integration with S3 and Glue environments. DuckDB 2.0, in preview since August 2026, promises a reworked parser engine — a sign the development pace is not slowing.
The thing to watch: the server-side roadmap
The neutrality promise lives in the governance, and that is where you look closely. The foundation is setting up a stakeholder advisory board that “can influence the direction of the projects.” Who sits on that board — and how much room AWS occupies — will determine whether technical choices stay balanced.
The risk is not the license, which is locked. The risk is orientation: a project whose vendor belongs to a cloud provider can see its roadmap pulled toward that provider’s ecosystem, even without a license change. DuckLake (the lakehouse format) and Quack (the client-server protocol) are exactly the server-side building blocks through which DuckDB could, tomorrow, deploy more naturally on AWS than with its rivals.
Why data teams can stay calm
Despite that caveat, the signal is clear. DuckLabs explicitly “lifted the limitations of community support” and said there would be “no changes for our projects’ roadmap, licensing, and governance model.” Concretely, three guarantees protect users:
- Irrevocable license: code already published under MIT cannot be re-licensed more restrictively.
- IP held by an independent foundation: the asset does not mechanically follow the acquirer.
- Multi-party governance: the advisory board opens the door to influence beyond AWS alone.
Structurally, this is the opposite of the Elastic scenario. An embedded MIT database under an independent foundation is one of the hardest open-source configurations to “close” after the fact.
From an academic trajectory to an industrial one
To measure the distance traveled, go back to the origin. DuckDB was born in 2018 at CWI (Centrum Wiskunde & Informatica) in Amsterdam, the Dutch lab that also produced MonetDB and VectorWise. Hannes Mühleisen and Mark Raasveldt — the latter earned his PhD there — built an embedded OLAP engine conceived as the “SQLite for analytics”: one database file, no server, SQL straight on files.
That research pedigree explains the community’s trust. Peter Boncz, the board’s third member, is the architect of MonetDB; the foundation is chaired by Mühleisen, a former data-systems professor at Radboud University. Passing 40,000 stars on GitHub, celebrated in August 2026, is not a marketing accident: it is the payoff of a project that stayed MIT, embedded, and serverless for eight years, where others would have given in to the proprietary-cloud temptation.
The precedent of licenses that close up
The DuckLabs acquisition does not happen in a vacuum. It reads against a decade of tension between open-source vendors and hyperscalers. MongoDB moved from AGPL to SSPL in 2018. Elastic left Apache 2.0 for SSPL and the Elastic License in 2021, after AWS launched competing distributions. Redis dropped BSD for the RSALv2 and SSPLv1 licenses in 2024. Each time the motive was the same: stop a cloud provider from reselling the software as a managed service without paying anything back.
DuckLabs makes the opposite choice. Rather than lock the license against the hyperscaler, it joins the hyperscaler — and neutralizes the risk by placing the IP in an independent foundation and keeping the MIT irrevocable. On paper, it is the most elegant exit from the dilemma: the commercial value goes to AWS, but the community asset stays out of reach of any license change. The only genuinely open question is the direction of the roadmap, not its ownership.
A signal for the whole embedded ecosystem
The DuckDB case goes beyond the database. It shows an embedded project can be acquired by a hyperscaler without the community having to flee. That is a useful counter-model at a time when infrastructure projects — databases, analytical engines, data tooling — are increasingly courted, and sometimes captured, by the big clouds. For data teams standardizing on open-source tooling, the existence of a foundation with public statutes and an irrevocable MIT becomes a selection criterion in its own right: it is the guarantee that the exit cost stays zero, even if the vendor changes hands.
The counterfactual worth considering
The test for whether this deal is healthy is a simple counterfactual: would the DuckDB community be better off if DuckLabs had instead relicensed under SSPL or raised a proprietary tier to fend off the clouds? Almost certainly not. Relicensing breaks downstream trust and forks the ecosystem; joining a hyperscaler while parking the IP in a foundation keeps the community whole and the code free. The history of Elastic and Redis is the cautionary tale that makes DuckLabs’s path look, by comparison, like the boring — and therefore good — outcome.
Verdict
If you already use DuckDB, you have no reason to migrate: the license is irrevocable, the IP sits in a foundation, and development continues. The acquisition changes nothing about your existing pipelines.
If you are evaluating DuckDB for embedded analytics, the news is actually reassuring — the durability of a project maintained by a company now backed by AWS is stronger, not weaker. Just keep an eye on two signals: the composition of the advisory board, and the future direction of DuckLake and Quack. If those server-side pieces stay cloud-neutral, the bet pays off on every front.