The reassurance you are being handed is real, and it protects the wrong thing. AWS is not acquiring DuckDB. Amazon's own announcement says so in one sentence: "We are not acquiring the DuckDB open source project, which will remain free and open source under the independent DuckDB Foundation…" That is true. It is also a statement about the code you already have, not about the code that gets written next.
What AWS is acquiring is DuckLabs — the Amsterdam company that employs the people who write DuckDB. Two of those people, Hannes Mühleisen and Mark Raasveldt, hold two of the three seats on the Foundation's board. When the deal closes in early September, a majority of the board that governs the "independent" Foundation will be on the acquirer's payroll. Nobody violated anything. The structure simply was not built for this.
What AWS Actually Bought
AWS bought payroll and commit history, not intellectual property. The AWS Big Data blog confirms the split precisely: the project will "remain open source under the independent Foundation… and available under the MIT license as it does today," while "Hannes Mühleisen and Mark Raasveldt… will continue leading the team and the open-source project's technical direction as part of AWS."
Read that last clause again. Technical direction, as part of AWS.
The concentration is what makes this matter. Pull the contributor list for duckdb/duckdb from GitHub's API and the top ten accounts have logged 54,234 commits between them — the single largest, Raasveldt's Mytherin, accounts for 26,102 of those on his own, more than three times the next contributor. This is not a project with a broad, distributed bench. It is a project with a small, extraordinarily productive team, and that team just got a new employer. The Register reports the financial terms were not disclosed.
The scale on the other side of that concentration is why this is your problem and not a niche governance story. DuckDB passed 40,000 GitHub stars on 5 August 2026, with "50M+ monthly downloads in PyPI, more than double the 20M we reported last time" and "over 8 million unique visitors" a month to duckdb.org. Most enterprises did not decide to adopt DuckDB. It arrived inside dbt adapters, notebook query engines, BI-as-code tools and eval harnesses, and it is now sitting in your dependency tree whether or not anyone signed for it.
The Foundation's Board Appoints Its Own Successors
The DuckDB Foundation's independence rests on three directors, and its own founding document lets those directors choose the next ones. The Foundation lists a three-person board: chair Hannes Mühleisen, Mark Raasveldt, and Peter Boncz, the CWI and VU Amsterdam researcher who is the only director not joining AWS.
The deed of incorporation for Stichting DuckDB Foundation is blunt about how that board renews itself: "Board members shall be appointed, suspended and dismissed by the Board." There is no member vote, no external appointing authority, no reserved seat for a neutral party. Board decisions carry on "an absolute majority of the votes cast representing an absolute majority of the number of Board members in office" — which, on a three-seat board, means two directors are decisive on everything, including who becomes the fourth director and whether there is one.
The deed does carry a conflict-of-interest clause: a director with a "direct or indirect personal interest… that conflicts with the interests of the Foundation" must declare it and abstain. That clause is doing more work than it can bear here. It turns on a personal interest, and an employment relationship is not obviously the same thing — XenoSpectrum's read of the bylaws notes that where abstention would make a decision impossible, the board can still decide provided it documents its reasons in writing. None of this is exotic. It is a completely standard Dutch stichting, and standard is the problem: it was designed to keep the IP out of a startup's cap table, not to arbitrate between an acquirer and its competitors.
A fix is on the table, and to be fair to the Foundation, its own announcement commits to one rather than merely floating it: the Foundation "will set up a stakeholder advisory board which can influence the direction of the projects." What that board can actually do is the part still missing. Mühleisen told The Register: "We are thinking about adding a Technical Advisory Board to the Foundation, so that whoever is betting on DuckDB can come together in the Board and have a communication channel through the Foundation, which stays independent." The same report notes the Foundation "has yet to decide the exact governance and voting rights which will determine the direction of the project's development."
A communication channel is not a vote. Until the charter exists, the advisory board is a promise with no defined authority, and the entity that would grant it authority is the board AWS now staffs. This is the same shape as the Ray control-plane problem — except there the open core was genuinely separable from the commercial layer above it, and here the thing being captured is the roadmap itself.
AWS Already Proved That Sponsorship Moves the Roadmap
We do not have to speculate about whether AWS money changes what DuckDB builds, because AWS has published the receipt. Andy Warfield, an AWS VP and distinguished engineer, describes the origin of the relationship over pints in Amsterdam: "We quickly agreed that AWS would become their customer and sponsor their Iceberg extension, with a goal of broadening support for Iceberg outside of the Spark landscape and making it as simple as possible to build applications over S3 Tables."
That is the mechanism, stated plainly and without embarrassment. AWS wanted an Iceberg extension that made S3 Tables easy to build on. AWS paid. The extension got built, and it is now a mature implementation of the Iceberg v2 and v3 specifications. Nobody was misled and nothing was hidden — it is simply evidence that the roadmap responds to whoever funds it.
The funding lever is not hypothetical elsewhere either. AWS is already a Gold supporter of the Foundation at €100,000 or more a year, alongside MotherDuck and Posit, and the Foundation's own pitch to members is that "Membership funds the roadmap and gives your organization a voice in it." The enumerated benefits of that voice are logo placement and hoodies. If a six-figure cheque buys a hoodie and an unwritten voice, the value of a controlling employment relationship is not hard to estimate.
Ashish Chaturvedi of HFS Research puts the practical version to InfoWorld: "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, whatever the governance charter says." He also does not recommend ripping it out — "The MIT license protects you from hard lock-in, and the engine keeps working everywhere" — but adds that "treating AWS as anything other than DuckDB's de facto owner now would be naive."
Your LTS Support Expires on September 16
If you pinned DuckDB to the current LTS, your community support window closes nineteen days from now, and the vendor that would sell you an extension is the one being acquired. DuckDB moved to a Long-Term Support model with 1.4.0: the release announcement states that "every other DuckDB version is going to be a Long-Term Support (LTS) edition" and that "for LTS DuckDB versions, community support will last a year after the release (for now)."
The release calendar puts a date on it. DuckDB 1.4.0 was released 16 September 2025; community support ends 16 September 2026. The 1.5 line is not LTS, and the same calendar puts its end of life at 1 September 2026 — earlier still, so switching to it buys no runway. The calendar does schedule one more patch, 1.5.6, for 16 September; note that this is the same day your 1.4 window shuts, not a later one. The sequence for anyone running 1.4.x is therefore: the acquisition becomes effective in early September, and your supported-version window closes about two weeks later.
That collides with a second change nobody flagged. DuckLabs sold support contracts — that was the business model. MotherDuck, writing within 48 hours of the announcement, says it is now entering that market: "We had avoided this in the past because we didn't want to compete with Duck Labs, who relied on this as their business model. Now that they are joining Amazon, we have the explicit blessing from Hannes and Mark that this won't be stepping on their toes." Meanwhile the project itself says it is lifting the limits on community support — a genuine improvement, since the old policy covered only a handful of extensions.
Net effect: from mid-September, your named commercial support counterparty for an embedded engine in your production stack is either AWS or the company AWS is about to compete with. That is a procurement decision, and it has a date on it.
The Strongest Case That This Is Fine
The optimistic reading is not stupid, and it comes from the party with the most to lose. MotherDuck — whose entire business is a DuckDB-based cloud warehouse, and whose largest future competitor is now its upstream's employer — came out in favour of the deal: "The DuckDB Foundation has iron clad control over the DuckDB IP, and DuckDB license is going to stay permissively open." They also say the quiet part without flinching: "Some day, Amazon will likely release their own service based on DuckDB. After all, they're not acquiring Duck Labs just because they love open source."
The substance behind that optimism is real. The Foundation holds most of the intellectual property and the trademarks for DuckDB, DuckLake and Quack, and it was incorporated in 2021 specifically to safeguard continuity under MIT. A perpetual MIT grant cannot be revoked on code already published. The engine will keep running on Google Cloud Storage and Azure Blob tomorrow exactly as it does today. And a company with more than thirty employees and a real support business has more resources than a volunteer project — that is genuinely better for the roadmap in the short run, particularly if you are already an AWS analytics customer.
None of that is in dispute. What is in dispute is a narrower question: who decides what gets built in 2028, and how would you know if the answer stopped being neutral?
The Last Time a Permissive License Wasn't Enough
The closest precedent is not a licence change at all — it is nginx, where the licence never moved and the project split anyway. F5 acquired Nginx Inc in 2019. The BSD licence stayed exactly as it was. Five years later, in February 2024, core developer Maxim Dounin announced freenginx, writing that "some new non-technical management at F5 recently decided that they know better how to run open source projects" and that he was "no longer able to control which changes are made in nginx within F5." His stated goal was to keep development "free from arbitrary corporate actions."
Note what triggered it. Not a rug-pull, not a relicense, not a paywall — a disagreement over security-release policy, five years after the acquisition, under an unchanged permissive licence. The exposure was never the licence. It was who decides.
The fork is also why "you can always fork it" is weaker advice than it sounds. A fork of a vectorised OLAP engine with a C++ core, an extension ecosystem and client bindings across a dozen languages requires a compiler-and-database-internals team you almost certainly do not have and cannot hire quickly. Forking is a real right. It is not a real plan. That distinction is the same one that mattered when Hugging Face put itself in play and when Nvidia hired 109 Poolside engineers without triggering a single contract clause: the artifact you hold is safe, and the future you assumed is a different question entirely.
What to Do Before the Deal Closes
This Week:
- Find DuckDB. Grep your lockfiles and SBOMs for
duckdb,duckdb-engine,dbt-duckdb,duckdb-wasm, the JDBC artifact, and the Node and Rust bindings. Most teams find it transitively — inside a dbt adapter, a BI-as-code tool, a notebook engine or an agent eval harness — rather than as a deliberate adoption. - Check your pin against the calendar. If you are on 1.4.x, write 16 September 2026 on the risk register today and decide whether you are waiting for the next LTS or buying support. Moving to 1.5.x is not the answer — the calendar retires that line on 1 September 2026, two weeks before your own date, and the last scheduled 1.5 patch lands on 16 September, matching your date rather than beating it.
- Read the change-of-control clause in any contract with a vendor whose product embeds DuckDB. The relevant question is not whether your vendor was acquired — it is whether their upstream was, and almost no contract covers that. The Descartes and Stripe deals both showed how narrowly those clauses are usually drafted.
This Month:
- Test the non-AWS paths you actually depend on, and record the result with a date: object storage on GCS and Azure via
httpfs, Iceberg REST catalogs that are not S3 Tables, and DuckLake with its metadata in Postgres rather than an AWS service. You want a baseline now so that any future divergence is measurable rather than arguable. - Pick a support counterparty on purpose. AWS after close, MotherDuck, or explicitly self-supported with a named internal owner. "We use the open source one" is not an answer once the LTS window shuts.
- Ask the Foundation, in writing, for the Technical Advisory Board's charter — composition, selection method, and whether it holds any vote. Put the question in email so the answer has a date on it.
Before Renewal:
- If you sponsor the Foundation, make the next cheque contingent on published TAB voting rights rather than logo placement. Gold membership is €100,000 a year; that is enough leverage to ask for a governance document.
- Write down your fork trigger. Not a plan to fork — a written condition. "If a non-AWS object-store path regresses and stays unfixed for two releases, we escalate." A condition you never hit costs nothing. A condition you never wrote costs you the argument.
The Bottom Line
Every open-source acquisition this year has been a lesson in reading the right document. Oakley bought Graphwise and the lesson was that the licence was never open to begin with. DoiT bought Attribute and the lesson was that the vendor measuring your cloud spend also sells it to you. Nvidia bought the Hugging Face compatibility layer and the lesson was that neutrality lives in an integration surface, not a logo. This one is different in a way that is easy to miss precisely because the licence really is safe: the IP stayed put, the MIT grant is perpetual, and the thing that changed hands was a payroll and two board seats.
That is the modern version of capture. Nobody has to relicense anything when they employ the people who decide. The same reasoning applies when you choose an embedded engine as when you self-host a vector database for residency rather than for the bill — you are not buying software, you are buying a decision-making process, and you should be able to name who runs it.
MIT is a floor, not a plan. Ask who votes.
Continue Reading
Ray Is Open Source. The Control Plane Above It Isn't. Oakley Bought Graphwise. GraphDB Isn't Open Source. Hugging Face Hired Bankers. Go Mirror Your Weights. Nvidia Buys the Bridge to Trainium. Go Grep Your Imports. Nvidia Hired 109 Poolside Engineers. No Clause Fired. Stripe Bought OpenRouter. A Toggle Is Not a Contract. Descartes Bought Tai. Your Only Lever Is 60 Days. Self-Host the Vector DB for Residency. Not for the Bill.