DuckLabs, the company behind DuckDB, announced on August 26, 2026 that it was joining AWS, and the deal closed on August 31, 2026. For a lot of data teams, the first question was whether to start planning an exit. That is the wrong question. The short answer: DuckDB stays open source under the MIT license, a nonprofit foundation still holds its IP, and nothing in the version you run changed, so most teams need no migration plan. The useful question is what a new owner can reach, and what it cannot.
We have built and maintained ColdFusion systems since 1998, so we have watched a core platform change hands twice: Allaire to Macromedia, then Macromedia to Adobe. That history is a good lens here, because DuckDB is set up very differently.
Is DuckDB still open source after joining AWS?
Yes. DuckDB, DuckLake, and the rest of the open-source stack stay under the MIT license, and the nonprofit DuckDB Foundation, not AWS, holds the copyright.
The license. A permissive license such as MIT lets anyone use, modify, and redistribute the code with almost no conditions. A grant already made cannot be pulled back from the code you run today. The worst case is a future fork point, not a lost dependency.
The copyright. Open the DuckDB license file and the copyright line names the Stichting DuckDB Foundation, not DuckLabs. The foundation holds the IP and keeps stewardship of the projects. It was created when DuckLabs spun out of the CWI research institute in Amsterdam, so it predates the AWS deal.
The version in your pipeline. Nothing in the build you run changed on September 1, 2026. For most teams, the correct amount of architecture change in response is zero.
That structure is the real difference from a proprietary platform. When ColdFusion changed owners, customers got the new owner's roadmap, and that roadmap was the whole continuity story. It has worked out, and ColdFusion is still in production in 2026 at our clients. With DuckDB, the continuity story sits in a license and a foundation that the buyer does not own.
What is worth watching under AWS
AWS owning DuckLabs does not change DuckDB's license, but it does change incentives, and incentives show up in defaults. Two threads deserve a calendar reminder, not a migration plan: extension signing and roadmap influence.
Extension signing. DuckLabs plans to let DuckDB run extensions signed by other developers and organizations. That can make the ecosystem more open. The detail that matters is the default trust policy: which signers DuckDB trusts out of the box, and who decides. Judge the implementation when it ships, not the announcement.
Who shapes the roadmap. The DuckLabs press release describes a new advisory board through which commercial users can give input on the project roadmap. That is a reasonable structure. It is also the channel where a hyperscaler's priorities will carry the most weight. Track whether the parts you can run anywhere keep pace with the parts that assume your data sits in S3.
The question to answer before the next deal
Every team should be able to say what breaks if the steward of a core dependency is acquired. The DuckDB deal is a free drill for that question. It is one of the first questions we ask about any system we inherit, and the answer usually lives in two places: the license file and the governance page.
- Who holds the copyright? A foundation or a broad contributor base is harder to redirect than a single company.
- What license covers the version you run? Permissive and already granted is the strongest position. A license the owner can change on the next release is a different bet.
- What does an exit cost? Estimate how much of your pipeline would notice if you pinned a version or moved to a fork.
If the answers are clean, the next acquisition is a news item. If they are not, the acquisition is not your problem. Your dependency diligence is.
If you are deciding where a data tool should live as part of a cloud move, that tradeoff is part of how we scope an AWS migration.