DuckLabs will become a subsidiary of AWS and DuckDB will remain MIT under an independent foundation. That foundation has a board of three seats, two are held by people going to AWS, and the board appoints itself. That’s the complete story, and almost nobody is telling it.
Status as of August 27, 2026: the deal is not closed. Amazon says the agreement is subject to “customary closing conditions” and expects to close “soon”, with no date. The founders’ post mentions early September. Any statement in the past tense about this acquisition today is incorrect.
On August 26, Mark Raasveldt and Hannes Mühleisen signed a post on duckdb.org announcing that DuckLabs — the Amsterdam company they built around DuckDB, now over 30 people — is joining Amazon Web Services. Amazon’s statement is careful in a way that deserves credit: “We are not acquiring the DuckDB open source project, which will remain free and open source under the independent DuckDB Foundation… and available under the MIT license as it does today.” Andy Warfield, the Amazon VP quoted in it, isn’t exaggerating anything. No financial terms were disclosed.
I want to be precise about what I am and am not arguing. I’m not saying AWS is about to change DuckDB’s license. It can’t, and said it won’t. I’m saying that the phrase everyone is repeating — the foundation keeps the license, so nothing changes — is carrying far more weight than it can bear, and that the document that decides how much weight it can bear is public, has three pages, and it looks like nobody read it.
What does the MIT license actually protect?
It protects the code that already exists. Every line published under MIT stays published under MIT, forever, for anyone: that’s irrevocable, and that’s why the highest-voted comment on Hacker News (1,066 points and 308 comments at the time of writing) is correct: “AWS acquired DuckLabs, NOT DuckDB. The DuckDB source code is still owned by the nonprofit DuckDB Foundation.”
That protection is real and it’s not nothing. If everything goes wrong, the community forks from the last MIT commit and keeps going. That exit exists.
What MIT does not protect is everything you actually plan for: what features get built, in what order and with what priorities; which extensions are maintained; whether the storage format evolves toward S3 and Iceberg or stays neutral; how fast your bug gets fixed. Licenses govern copies. Roadmaps govern value, and roadmaps are governed by people. Ashish Chaturvedi, from HFS Research, said it to InfoWorld more directly than I would: “Developers shouldn’t mistake an unchanged license for an unchanged project. The people writing the bulk of DuckDB’s core code now cash AWS paychecks, and paychecks bend roadmaps.”
And a fork isn’t a plan either. It’s a disaster recovery procedure, and like any procedure of that kind, its cost is measured in people you’d have to hire.
What is DuckDB and how does it differ from SQLite?
It’s worth defining the subject, because a lot of your exposure depends on that difference.
DuckDB is an embedded analytical database: it runs inside your process, no server to manage, just like SQLite. The difference is what each one is built for. SQLite is transactional and row-oriented: it’s designed to read and write individual records, which is what an application does. DuckDB is columnar and vectorized: it’s designed to sweep through millions of rows and aggregate them, which is what an analytical query does.
In practice this means they don’t compete as much as it seems. SQLite stores your application’s state; DuckDB answers questions about your data — querying Parquet, CSV, or Iceberg tables directly — without you having to spin up a data warehouse. Alongside DuckDB, the same team maintains DuckLake (lakehouse format) and Quack, and all of that is what the announcement calls the “Duck Stack”.
That detail matters for what comes next: the embedded part and the lakehouse part have very different exposures to a strategic owner who already has S3 Tables and Iceberg in their portfolio.
Who governs the DuckDB Foundation?
Here’s the part I didn’t see covered anywhere, in any language.
The foundation’s page says it’s an independent nonprofit organization and that “the foundation holds much of the intellectual property (IP) of the project”. It lists three board members: Hannes Mühleisen, Mark Raasveldt, and Peter Boncz. It’s financed by donations, with Silver membership from €10,000 and Gold from €100,000; the listed Gold supporters are Voltron Data, MotherDuck, and Posit, with Cloudflare as technical sponsor.
The founding act of Stichting DuckDB Foundation is published as a PDF on duckdb.org, and it answers the question. Its stated purpose is “to promote the continuity of the DuckDB software, by making and keeping the software generally accessible and available” and to manage intellectual property rights over the code and architecture. Then come the governance clauses:
- The board appoints itself. “Board members shall be appointed, suspended and dismissed by the Board.” There are no members, no electorate, no sponsor seats. Gold membership buys a logo, not a vote. If the board became completely vacant, CWI INCUBATOR B.V. can appoint one member.
- Seats are indefinite and the board defines its own size. It started with three; there are no terms or renewals.
- The board can rewrite its own bylaws. “The Board is authorised to amend the Articles of Association”, with all members present or represented.
- Removing a member requires all the others. A member leaves by “resignation granted by the Board pursuant to a resolution adopted by all other Board members.”
- The only mechanism for conflicts is case-by-case decision. “A Board member shall not participate in the deliberations and decision-making if he has a direct or indirect personal interest in doing so that conflicts with the interests of the Foundation.” That’s a rule of abstention, not a structural rule, and each member evaluates it themselves.
Now count. Two of the three seats belong to the founders who will be running DuckLabs inside AWS from September on. Nothing in the announcements says either of them will leave the board, and nothing in the act requires it: there’s no clause about employment, affiliation, or vendor neutrality anywhere in the document. So the institution that holds the IP, and that can modify its own charter, will very likely end up with a two-thirds majority employed by the buyer.
I don’t read it as a maneuver. This structure was built in 2021 for a research spin-off, and for that it was appropriate. It just wasn’t designed to withstand a hyperscaler, and now it’s being cited as if it were.
The announced remedy doesn’t solve it either, and the two announcements don’t even describe it the same way: duckdb.org mentions an advisory board of stakeholders, while ducklabs.com says “technical advisory board, so that leading community members can provide their input on the project’s technical direction”. Both words matter. Input is not a vote, and an advisory board that doesn’t appear in the bylaws can be dissolved by the body it advises.
What happened with OpenSearch and Elasticsearch?
It’s the obligatory question, because it’s the only precedent where AWS is the protagonist. And the answer is better than the company’s reputation, with an asterisk on timing.
In 2021 Elastic changed Elasticsearch to the SSPL license. AWS made a fork and called it OpenSearch, keeping it under Apache 2.0. And on September 17, 2024 it transferred the project to the Linux Foundation as OpenSearch Software Foundation, with a technical steering committee and a governance board with membership classes: AWS, SAP and Uber as premier, along with general members that include Aiven, Atlassian, Canonical, DigitalOcean, Graylog and Instaclustr. The project’s principles page commits in writing that “we will not tweak the software so that it runs better for any vendor (including AWS) at the expense of others”. There is no CLA.
That is a real and documented transfer of control by AWS, and whoever argues that the company is structurally incapable of doing so has to explain OpenSearch.
But look at the form. It took three years, and it happened to a project that AWS had created and controlled completely, under competitive pressure from a fork that it had made itself. Which means that the OpenSearch precedent is not a guarantee that DuckDB’s governance is sound today. It’s the description of the destination — a multi-vendor board with defined membership classes and written neutrality commitments — and a measurement of how long the journey took last time.
The distance between a Linux Foundation governance board and three self-appointed seats is not a detail. It is exactly the distance between the promise being made and the structure that supports it.
What would I do now?
None of this justifies pulling DuckDB from anywhere. It’s MIT, it’s embedded, there’s no server they can disconnect you from, and the code you have today is yours forever. That’s a genuinely solid position — considerably more solid than anyone had when Elastic or Redis changed terms, because here there’s no license they can change underneath you.
What it does justify is deciding, deliberately and this month, how much of your architecture depends on decisions now being made by people who work for a single cloud provider.
- Pin your version and note what it is. MIT protects the commit you have. That protection is only real if you know what that commit is and can compile from there.
- Separate DuckDB from DuckLake in your risk register. The embedded engine and the lakehouse format have very different exposures to an owner with Iceberg and S3 Tables in their portfolio. Treat them as two decisions.
- Inventory your extensions by maintainer. The core is the safest part of all this. Extensions with a single corporate maintainer are where a diverged roadmap shows up first.
- Ask, in writing, whether the founders remain on the foundation’s board after closing. It’s a fair question, answerable, costs nothing to ask, and the answer tells you more than the three announcements combined.
- Watch what the advisory board becomes, not that they announced it. The signal to look for is a change to the bylaws that creates seats AWS doesn’t control. If in twelve months the advisory board exists but the statutory board still has three seats, you already have your answer.
- Calculate the cost of your fork once, then stop thinking about it. Not to execute it: to know the number. For most teams it’s small, and knowing it’s small is what lets you adopt with peace of mind instead of covering yourself expensively.
The most likely outcome here is good: a well-funded team delivering faster under a permissive license, exactly as promised. I just prefer to sustain that expectation because I reviewed the structure and not because a press release told me the foundation is independent.
Do you have DuckDB in production today? I’m especially interested if you’re using it embedded within an application or as a query layer over a lakehouse, because the exposure to this deal is not the same in the two cases.