AWS is buying DuckLabs. The check that matters is board composition, not paper.

Short version: AWS announced today that it is acquiring DuckLabs, the Amsterdam company behind DuckDB, with the deal closing in early September. The code is not the exposure. DuckDB is MIT, MIT code that has already shipped cannot be un-licensed, and an independent distribution is already being built and signed outside the project. The exposure is governance, and governance here comes down to a three-seat board. The DuckDB Foundation holds the core IP; two of its three directors are DuckLabs co-founders who become AWS employees at close; and the articles of association the Foundation publishes on its own site do not contain the word MIT, the word license, or the phrase open source anywhere, even though the project FAQ says the statutes guarantee MIT in perpetuity. That gap is far more likely to be a documentation problem than a plan. It is still the thing I would want cleared up, and the paperwork that would clear it up is a smaller ask than most people arguing about this deal seem to think.

What was actually announced

Two posts went up on 2026-08-26. AWS says it is acquiring DuckLabs and that the company will become an AWS subsidiary, with the sentence everyone is quoting: "We are not acquiring the DuckDB open source project, which will remain free and open source." DuckLabs says, in a post signed by Mark Raasveldt and Hannes Mühleisen, that "there are no changes for our projects' roadmap, licensing, and governance model," that DuckDB, DuckLake and Quack stay MIT under the nonprofit DuckDB Foundation, and that a stakeholder advisory board will be established.

The company is the thing being bought. DuckLabs was founded a little over five years ago as a spin-off from CWI, the Dutch national research institute where DuckDB started, and grew to more than thirty people in Amsterdam. It never raised. Their own framing: "venture capital firms were calling. We chose a different path: a bootstrapped company, fully owned by its founders and development team."

Terms were not disclosed. Anyone quoting you a number is guessing.

The strongest version of the case for this deal

I want to put this before the critique, because it is genuinely good and it is the part most of the commentary skipped.

DuckLabs gave a capacity reason, not a payday reason: "our small company could become a bottleneck for the project." That is a real failure mode for a thirty-person company maintaining something this widely deployed. PyPI recorded 1,762,042 duckdb downloads in a single day and 66,965,791 over the trailing thirty days when I checked today (pypistats), against a repository sitting at 40,660 stars. Nine days before this announcement they shipped a preview of DuckDB v2.0 declaring that "this release kicks off the year of DuckDB as a server," with an asynchronous I/O layer that "scales independently from the query processing layer." Turning an embedded analytics engine into a server is not a small amount of work, and it is exactly the kind of work that stalls when the maintainers are also running a support business.

The second argument is better still, and it is buried in the AWS release: "Following the transaction, DuckLabs will no longer depend on converting users of its free software into commercial support customers." That is the open-core pressure valve, released. Every self-funded OSS company eventually faces a choice between what the project needs and what makes the enterprise tier look worth buying. DuckLabs will no longer have to make that trade. If you have watched a beloved tool grow a suspiciously load-bearing paid feature, you know how much that is worth.

More money and more engineers on the server year, with the incentive to hobble the free version removed. That case is strong and I do not think it is a smokescreen.

Why the Foundation is the load-bearing part

The reason people are calm about this deal is the Stichting DuckDB Foundation, the Dutch nonprofit that holds the core IP. The project's own FAQ puts it plainly: "Most of the intellectual property of DuckDB has been purposefully moved to a non-profit entity to disconnect the licensing of the project from the commercial company, DuckLabs."

That structure is real and it was set up years before anyone was thinking about an acquisition. But it only does work if the Foundation is independent of the company, and independence here is not a document, it is a roster. As of today, the Foundation's site lists exactly three board members: Hannes Mühleisen (Chair), Mark Raasveldt, and Peter Boncz. Mühleisen and Raasveldt are the DuckLabs co-founders. At close, both become AWS employees. Boncz is at CWI and VU Amsterdam.

Two of three seats. No change to the board has been announced in either direction, and I am not going to assume one. But the arrangement the FAQ describes, where the nonprofit exists to disconnect licensing from the commercial company, reads differently once a majority of the nonprofit's board draws a paycheck from the buyer.

What the published articles of association say

The Foundation links its own charter from its site as "Articles of Association (English)". It is the deed of incorporation, executed 25 October 2021 at Zeist, seven pages, in English, marked as issued as a copy. I read all of it. Here is what is in there, verbatim.

The purpose, Article 3:

to promote the continuity of the DuckDB software, by making and keeping the software generally accessible and available; to hold and manage the intellectual property rights on the source code and architecture of the 'core' of the DuckDB software; actively to further develop the DuckDB software and further define the further development strategy of the DuckDB software; to propagate the ideas behind the DuckDB software and promote awareness and use of the DuckDB software; all in the broadest sense of the word.

The board, Article 4:

4.1 The Board consists of a number of members to be determined by the Board.

4.2 Board members shall be appointed, suspended and dismissed by the Board.

Appointments run for an indefinite period (4.4). The board sets its own size, fills its own seats, and removes its own members. There is no external appointer, no member class, no community vote. Article 4.7 provides a single fallback: only if no board member is in office at all may CWI INCUBATOR B.V. appoint one board member. That clause is a fire escape for a vacant board, not an ongoing check on a sitting one.

Article 9.1: "The Board is authorised to amend the Articles of Association." Article 10.1: "The Board is authorised to dissolve the Foundation."

And Article 5.1, on what directors owe: board members "shall focus on the interests of the Foundation and its affiliated company or organisation."

Now the part that surprised me. The words MIT, open source, and license do not appear anywhere in Articles 1 through 12 of that document. It commits the Foundation to keeping DuckDB "generally accessible and available" and to holding the core IP. It does not name a license, and on its face it does not bind a future board to one. Everything in this section describes the deed as published; whether it is still the text in force is the open question I come back to below.

The FAQ says something the published deed does not

duckdb.org/faq states, twice, in identical words: "The DuckDB Foundation's statutes also ensure DuckDB remains open-source under the MIT license in perpetuity."

I cannot find that in the statutes the Foundation publishes. I looked for it specifically, because I expected to find it.

I want to be careful about what that means. A FAQ is documentation, not a legal instrument. Nobody signs a FAQ. The most likely explanation by a wide margin is that someone wrote a sentence describing the intent of the structure, which is accurate as intent, and the sentence hardened into a factual claim about the text through repetition. It is the kind of drift that happens on every docs site I have ever worked on. The fix is an edit, or better, an amendment.

What I would not do is repeat the FAQ's sentence as if it were a property of the deed, because that sentence is now doing a lot of load-bearing work in public arguments about this acquisition. MotherDuck's CEO Jordan Tigani wrote today that "The DuckDB Foundation has iron clad control over the DuckDB IP." He is right that the Foundation holds the IP, and he knows this project and this ecosystem far better than I do. My reading complicates the second half rather than the first: on the articles as published, control of the IP sits with a board that appoints itself and can amend its own articles, so the strength of the arrangement is the strength of the people in those three chairs.

The part I cannot verify, stated plainly

The PDF on the Foundation's site is the 2021 deed of incorporation. Article 9 lets the board amend the articles, and no amended or consolidated text is published anywhere I can find. So I do not know whether the current statutes match the document I read. They may well have been amended since, possibly to add exactly the MIT clause the FAQ describes.

That is the weakest link in this post and I would rather say it in a heading than bury it. My claim is narrow and I will keep it narrow: the articles of association the Foundation publishes today contain no license clause. I am not claiming the Foundation is free to relicense DuckDB at will, and I am not claiming anyone is hiding anything. Publishing the consolidated articles would resolve the whole question in an afternoon.

Four reasons this is not a crisis

Already-released MIT code can never be un-licensed. Every version of DuckDB that has shipped is MIT forever, to everyone who has it, with the right to fork. Nothing a board does in 2027 reaches backwards. The exposure is future direction, trademarks, and the extension signing keys, not the code you already depend on.

Somebody already builds DuckDB independently, and started before the deal. Haybarn is Query Farm's self-described "independent derived distribution" of DuckDB, not a hostile fork: same SQL, same database files, same extension names, rebuilt and signed under its own trust root, with a separate community-extensions channel. Its repositories went up on 14 May 2026, months before anyone knew AWS was buying anything, and it states plainly that it is "not affiliated with, sponsored by, or endorsed by the DuckDB Foundation or DuckDB Labs." It is not an escape hatch anyone has needed to use. It is proof that the machinery for one exists and works: an outside party can already build the engine, re-sign the extensions, and ship the result without upstream's permission.

Dutch stichting law is a real constraint, not a formality. A board that can technically do something is not a board that may lawfully do it. Article 3's purpose and Article 5.1's duty bind directors to act in the interest of the Foundation, and Dutch courts can intervene against a stichting board acting contrary to its stated purpose, including by dismissing directors. A relicensing that made DuckDB less "generally accessible and available" would run straight into the purpose clause. That is a slower and messier remedy than a license clause in the articles, but it is not nothing.

There is no CLA. DuckDB's contributor guidance asks for no copyright assignment and no contributor license agreement, so outside contributions stay with their authors under MIT. Copyright in the codebase is therefore distributed rather than consolidated, which makes a hostile relicense of the whole thing considerably harder than a single-owner project where one signature covers everything.

AWS inherits a stake in MotherDuck

One detail worth stating precisely, because the entity matters. The DuckDB FAQ says: "MotherDuck contracts with DuckLabs for development services, and DuckLabs owns a portion of MotherDuck." DuckLabs owns that stake, not the Foundation. AWS is buying DuckLabs. So at close, AWS holds equity in the leading independent DuckDB cloud, which is also the company most exposed if AWS ever decides to offer DuckDB as a service itself.

Tigani expects that service to arrive, writing that it is "Amazon's playbook, after all: wait until an open source project gets big enough, then launch it as a service." AWS has neither committed to nor ruled out a managed DuckDB. I am not going to predict it. I will note that AWS and MotherDuck were both already listed as Gold supporters of the Foundation, its top funding tier, so AWS was not a stranger to this project before today.

If you are a MotherDuck customer, the practical questions are unchanged from the ones I wrote up in MotherDuck alternatives and in the 2026 pricing changes, which is where all the dollar figures live. The acquisition adds a governance question on top; it does not change the shape of the product.

The precedent that argues against panicking

When Databricks bought Neon, the consensus prediction was a price hike and a slow enterprise-ward drift. Storage dropped roughly 80 percent, compute on the entry plan came down, and the free tier doubled. I wrote that up in Neon after Databricks, and the cuts have held since. The concerns in that post were about eighteen-month drift and pre-IPO pricing incentives, not about anything the acquirer did in the first month.

Big-company acquisitions of developer infrastructure do not reliably ruin the thing in the short run. They change whose priorities set the roadmap over years. Treat this the same way: today's DuckDB is excellent and today's commitments are made in good faith. What to keep an eye on over the next couple of years is the board roster, and after that the trademark policy and the extension signing keys, which are the levers that would actually affect anyone downstream.

What would settle this

None of this needs a lawsuit or a fork. Three pieces of paperwork would close the entire question:

1. Publish the current consolidated articles of association, so the public text matches the operative one.
2. Amend Article 3 or 4 so the license commitment lives in the deed rather than in a FAQ, along the lines of an entrenchment clause that a future board cannot quietly amend away.
3. Say what the board will look like after close, and whether the announced stakeholder advisory board carries any appointment or veto right or is purely consultative.

If those land, this becomes a well-governed project with a large funder, which is a genuinely good outcome for everyone using DuckDB. Until they land, the honest description is a project protected by the judgment of three people, two of whom will shortly have a new employer.

Where DuckDB runs while this plays out

I run DuckDB on Layerbase Cloud, on the free plan, and nothing about today changes what it does. It is plain upstream DuckDB from the 1.5 line with no proprietary execution layer and no rewritten SQL, reachable over the PostgreSQL wire protocol on port 5432 because DuckDB has no network protocol of its own (more on that in DuckDB 1.5 on Layerbase). Connect with psql or any Postgres driver using ?sslmode=require, and SELECT version() will tell you it is Duckgres over DuckDB. The httpfs extension autoloads on demand, so read_parquet and read_csv_auto over an https URL work without a setup step. The Free plan is $0 with no card, and covers 2 databases, 5 GB of storage, and up to 20 concurrent connections.

I am not going to pretend that hosting DuckDB somewhere else insulates you from any of the above. It does not. The upstream project is the upstream project no matter who runs it for you, and I am not making a claim about whose hardware anything sits on. The one thing I can say cleanly is about ownership: Layerbase is not owned by a hyperscaler, so nobody's cloud strategy is upstream of what we do with your database. If that distinction matters to you right now, it is a free database and a five-minute test.

FAQ

Is DuckDB still open source after the AWS acquisition?

Yes. DuckDB, DuckLake and Quack remain MIT licensed under the nonprofit DuckDB Foundation, and AWS stated explicitly that it is not acquiring the open source project. Beyond the commitments, every release that has already shipped is MIT to everyone who has it, permanently, so no future decision by any party can retroactively close code you already depend on.

Does the DuckDB Foundation's charter guarantee the MIT license?

The project FAQ says the statutes ensure DuckDB stays MIT in perpetuity, but the articles of association the Foundation publishes on its own site do not mention MIT, licensing, or open source anywhere. That published document is the 2021 deed of incorporation, and since the board is authorized to amend the articles and no amended text is published, it is possible the current statutes differ from the copy anyone can read today. The most likely explanation is a documentation gap rather than anything deliberate, and publishing the current consolidated articles would resolve it immediately.

Who controls the DuckDB Foundation?

Its board, which as of today has three members: Hannes Mühleisen as chair, Mark Raasveldt, and Peter Boncz. Under the published articles the board determines its own size and appoints, suspends, and dismisses its own members, with no external appointer except a narrow fallback letting CWI Incubator name one director if no board member is in office at all. Mühleisen and Raasveldt co-founded DuckLabs and become AWS employees when the deal closes, so two of the three seats change employer. No change to the board has been announced in either direction.

Could AWS relicense DuckDB?

Not the code that already exists, which is MIT forever and can be forked by anyone. A future relicense would apply only to new work, would require the Foundation board to act, and would run into two obstacles: Dutch foundation law binds directors to the Foundation's stated purpose of keeping the software generally accessible, and a court can intervene against a board acting against that purpose. DuckDB also has no contributor license agreement, so copyright in contributed code stays with its authors and is not consolidated in one owner.

Should I move off DuckDB because of this?

No. The engine is excellent, the released code cannot be taken away, and there is no evidence of bad intent from either party. The reasonable response is to watch governance rather than to act: whether the current articles get published, whether the license commitment ends up in the deed instead of a FAQ, what the board looks like after close, and what happens to the trademark and the extension signing keys. An independent distribution called Haybarn already builds and signs DuckDB outside the project, so the capability to go your own way exists if the situation ever deteriorates.

What happened to Neon after Databricks acquired it?

Prices went down rather than up. Storage fell around 80 percent, entry-plan compute got cheaper, and the free tier doubled, and those cuts have held since. It is the useful counterweight to acquisition panic: the risk from a big-company acquisition usually shows up as roadmap drift over a couple of years, not as an immediate degradation of the product you are using today.

Where this leaves you

DuckDB is in better shape today than it was yesterday in every way that money and headcount can fix, and the conversion pressure that warps most open-core projects is gone. The structural protection people are pointing at is thinner than the FAQ describes, but the remedy is paperwork rather than a fight, and the DuckDB team can do it whenever they like. I hope they do, because I would rather cite a clause than a promise.

Meanwhile the engine keeps running the same everywhere. Create a free DuckDB database on Layerbase Cloud and keep your options open.