The EU Team Behind DuckDB Just Joined AWS

Ten Years, One Signature

Hannes Muhleisen and Mark Raasveldt spent close to a decade building DuckDB, starting as a research project at Amsterdam's Centrum Wiskunde and Informatica before they spun it out as an independent company, DuckLabs. On August 26, 2026, Amazon announced a definitive agreement to acquire that company.

DuckDB earned its following by doing the opposite of what most database vendors sell: it runs inside your own application, on your own laptop or server, with no cloud account, no network call, and no vendor to bill you by the query. That design made it a default pick for EU teams building self-hosted analytics pipelines they could audit, move, or shut down without asking anyone's permission.

What AWS Actually Bought

AWS bought the company, not the code. Amazon's announcement is explicit that DuckLabs, the roughly 30-person commercial entity, joins AWS in full, while the DuckDB open-source project remains MIT-licensed and stewarded separately by the independent, non-profit DuckDB Foundation. No financial terms were disclosed, and the deal is expected to close within weeks, pending customary conditions.

Muhleisen and Raasveldt keep directing the open-source project's technical direction, and AWS says nothing changes for existing DuckDB users before the deal closes. Andy Warfield, an Amazon vice president and distinguished engineer, described two years of prior collaboration with the DuckLabs team ahead of the acquisition.

A Rival Named The Pattern Out Loud

Jordan Tigani runs MotherDuck, a company that built a commercial cloud product directly on top of DuckDB and now competes with whatever AWS builds next. He described the acquisition as a predictable move: wait for an open-source project to get popular enough, then bring its stewards in-house to turn that popularity into a managed cloud service.

Tigani's read is not entirely hostile. He argues Amazon now has a direct financial incentive to keep DuckDB open, well-maintained, and widely adopted, since every new DuckDB deployment is a potential source of AWS compute revenue down the line. Both things can be true: the incentive to keep the project healthy is real, and so is the incentive to shape its future in AWS's direction.

The Gap A Procurement Checklist Misses

Choosing an open-source, self-hosted tool over a cloud vendor is a standard sovereignty move for EU teams weighing GDPR data residency, audit rights, or exit costs. That move protects the code you run today. It says nothing about who employs the small group of people actually writing tomorrow's code.

DuckLabs was about as close to sovereignty-friendly as a database company gets: Amsterdam-based, EU-incorporated, MIT-licensed, with a business model built on support and hosting rather than lock-in. It still ended up inside a US hyperscaler the moment its user base made that acquisition commercially worthwhile. A procurement checklist that only asks about license and hosting location never asked where the maintainers cash their paychecks.

What The Foundation Actually Protects

The MIT license and the independent DuckDB Foundation are real, enforceable protections, not marketing language. Any organization can fork DuckDB today, keep running the current codebase forever, and owe AWS nothing for it.

What the license does not protect is momentum. Forking is a legal right that almost nobody exercises in practice, because the value of an open-source project lives in its active maintainers, not its frozen source code. For as long as Muhleisen and Raasveldt keep setting DuckDB's roadmap, that risk stays theoretical. The acquisition is the moment EU teams running DuckDB in production should write down what they would actually do if that ever changed.

Read next: Amazon Backs a 7.65-Gigawatt Private Gas Plant  |  OpenAI's Agent Platform Has One Cloud Reseller