On 26 August 2026, Amazon announced a definitive agreement to acquire DuckLabs, the Amsterdam company founded by Hannes Mühleisen and Mark Raasveldt to build and support DuckDB. The deal is expected to close in early September. Terms were not disclosed.
Read the announcements and there is very little to object to. Amazon is not acquiring the DuckDB project: DuckDB, DuckLake and the extension ecosystem stay under the MIT licence, stewarded by the independent non-profit DuckDB Foundation, which holds the intellectual property. The founders keep leading the team and setting technical direction. DuckLabs continues as a wholly owned subsidiary, a stakeholder advisory board is being established, and the two organisations have worked together since 2024, so this is a deepening rather than a surprise.
Every structural safeguard open source governance has to offer was in place before the deal, and every one held. That is the interesting part, and why this deserves twenty minutes of your CTO’s attention rather than a shrug.
TL;DR
- AWS is acquiring DuckLabs, not DuckDB. The project stays MIT-licensed under the independent DuckDB Foundation, which holds the IP, and the founders remain in charge of technical direction.
- Most open source risk registers track one failure mode: a licence pivot to BSL or SSPL. This deal is the other one, where the licence is genuinely safe and the stewardship changes hands anyway.
- A permissive licence guarantees your right to fork. It does not guarantee that forking is affordable, and for a vectorised query engine it emphatically is not.
- What transfers in a steward acquisition is attention: roadmap priority, review latency, which integrations become first-class, and which use cases quietly stop being optimised for.
- The practical response is an inventory and a set of tripwires, not a migration. Panic-migrating off a healthy dependency costs more than the risk you are avoiding.
The safeguard everyone cites is narrower than it sounds
The reassurance doing most of the work here is the foundation structure. MotherDuck, whose entire business is built on DuckDB, put it plainly: the foundation has iron-clad control over the IP and the licence stays permissive. That is true, and deliberate. The foundation exists precisely so that no single commercial party can do to DuckDB what HashiCorp did to Terraform or Redis did to Redis.
But notice what that protection covers. It guarantees the code stays MIT. In practical terms, it guarantees your right to fork, and a right to fork is a right to a bill.
Forking a linter is a weekend. Forking an in-process vectorised OLAP engine means owning a query planner, a storage format, an execution engine, an extension ABI and a compatibility surface the rest of the ecosystem will keep moving away from. Almost no organisation outside the largest data platform vendors can carry that. The licence is a real protection against one specific abuse; it is not a substitute for the project continuing to be run in a way that suits you.
We made a related point when Cal.com, HashiCorp and Redis pivoted their licences. The lesson then was to vet dependencies for the possibility of a rug pull. The lesson now is subtler: a dependency can be entirely safe from a rug pull and still stop being the dependency you chose.
What actually changes hands
Nothing in the licence, and nothing on the roadmap this quarter. What changes is where attention comes from, and attention determines a project’s shape over three to five years.
Roadmap priority. An independent consultancy prioritises by what its clients and its community push hardest on. A hyperscaler subsidiary prioritises by what makes the parent’s platform better. Those lists overlap heavily today, which is why the deal makes sense, but not perfectly. Deeper S3 and Iceberg integration is close to a certainty. Work that mainly benefits a competing object store, or a local-first desktop workload with no cloud component, competes for the same hours without an internal sponsor.
The definition of first-class. Every mature project has a supported path and a tolerated path. Acquisitions rarely delete the tolerated path; they stop investing in it. Documentation goes stale, the benchmark suite stops covering it, the friendly bug turnaround becomes a slow one. Nobody announces this and nobody is acting in bad faith. It reflects where the reviewers now spend their days.
People. The most-repeated concern in the 200-plus comment Hacker News thread was not licensing at all. It was whether people who built something this good in a small Amsterdam team will still be doing it in three years inside a very different operating culture. No foundation charter addresses that. The MySQL and Oracle precedent gets cited so often because the licence survived there too.
The exposure most teams miss is one layer up
If you use DuckDB directly, embedded in a service or a notebook, your exposure is modest and your exit is real: it is a file format and a SQL dialect.
The sharper exposure belongs to teams whose vendors are built on it. A product whose entire value proposition sits on DuckDB now has an upstream owned by the largest competitor in its market. MotherDuck’s response was optimistic and disarmingly honest about this, conceding the post might look hopelessly naive in a few years, and that it may be a case of inviting the wolves over for a dinner party. They are probably right and it works out. It is still a change in the risk profile of anything you built on them, and one you did not make.
It is the open source sustainability problem from the opposite direction: there an under-resourced maintainer burns out, here a well-resourced one acquires a strategic parent. Both change who the project is ultimately for.
A steward audit you can run this week
Half a day for one senior engineer, and worth doing whether or not you use DuckDB.
- List the ten dependencies you could not replace in a quarter. Not your lockfile, the short list: databases, queues, auth, build toolchain, the framework everything is written against.
- For each one, name the steward, not the licence. Who employs the people who merge pull requests? A foundation with plural corporate backing, a single venture-funded company, a hyperscaler subsidiary and one unpaid person are four completely different risk profiles that look identical in a licence audit.
- Ask what the steward sells. A project’s rough edges get smoothed in the direction of its steward’s revenue. That is not cynicism, it is where the funded hours go. If your use case is orthogonal to that revenue, note it.
- Price the fork honestly. Engineer-months to carry a hard fork for twelve months, not the fantasy version. If the answer is more than a small team, stop treating the licence as your mitigation and write down what your actual mitigation is.
- Set tripwires rather than deadlines. Observable signals: founders departing, median time-to-merge on community pull requests doubling, a feature shipping in a managed offering months before the open source release, a release cadence slipping twice running. Review them quarterly.
- Keep the exit warm where it is cheap. Standard SQL over vendor extensions, open table formats over proprietary ones, one adapter layer rather than the dependency’s types threaded through your domain model. Good architecture regardless, which is what makes it worth doing before you need it.
What not to do
Do not migrate. We say it bluntly because we have watched teams burn a quarter re-platforming away from a healthy dependency on the strength of a headline, and land on something worse maintained with a smaller community and no support option at all. On the evidence available today this deal is a good outcome for DuckDB: better funding, the same people, the same licence, and community support limits lifted rather than tightened.
The correct response to a steward change is almost never to act. It is to know your position, to have decided in advance what would change your mind, and to have someone whose job it is to notice. Most organisations fail at the first, which is why the third never happens.
Contrast it with the case where you have no protections at all. When a proprietary dependency is acquired, as with Stripe’s purchase of OpenRouter, the licence question never arises, because there was never a licence protecting you. Open source at least gives you a floor. The mistake is confusing a floor with a roof.
The underlying point
Dependency risk is usually assessed once, at adoption, against a checklist of licence, stars and release cadence. All three can stay green while the thing you actually depend on, a group of people choosing what to work on next, changes entirely.
The DuckLabs deal is a good news story with a useful lesson attached, and the lesson is not “open source cannot be trusted”. It is that governance protects the code and nothing protects the attention. Know which of your dependencies you are renting attention from, and from whom.
At REPTILEHAUS we build and maintain production systems for entrepreneurs, management teams and other agencies, and platform risk is part of every architecture review we run, because it is cheap to plan for and ruinous to discover. If you cannot name the steward behind your five most critical dependencies, get in touch.
📷 Photo by Ricardo Gomez Angel on Unsplash
