AWS Is Buying the Company Behind DuckDB and Explicitly Not Buying DuckDB. Here Is What Actually Transfers.

Amazon announced on August 26 that it has signed a definitive agreement to acquire DuckLabs, the Amsterdam company behind DuckDB. The announcement contains an unusual sentence for an acquisition post: "We are not acquiring the DuckDB open source project, which will remain free and open source under the independent DuckDB Foundation and available under the MIT license as it does today."

Four days ago I wrote that DuckDB 2.0's server mode deletes a whole tier from the solo operator stack. The timing is funny, and it would be dishonest to pretend it did not make me re-read my own post. So here is the sober version: the license is not what I was worried about, and it is not what you should check either.

What the announcement actually commits to

The concrete parts are short. The DuckLabs team stays in Amsterdam and joins AWS when the deal closes, which Amazon expects "shortly." Hannes Mühleisen and Mark Raasveldt, who created DuckDB and co-founded DuckLabs, continue leading the team and the project's technical direction. AWS and DuckLabs have worked together since 2024, and Andy Warfield, an Amazon VP and distinguished engineer, described two years of close collaboration already. Press coverage puts the team at more than 30 engineers. Amazon did not disclose a price.

The project itself sits with the DuckDB Foundation, a Dutch nonprofit that was set up years ago precisely so the code would not live inside the company. That structure is why Amazon can truthfully say it is buying a company and not a database.

The license was never the exposure

The pattern everybody reaches for here is Elasticsearch, or Redis, or Terraform: company owns the code, company changes the license, community forks in a hurry. That pattern does not apply cleanly when a foundation holds the copyright and the license is MIT. MIT is irrevocable for the code already published. Even in the worst case, every line of DuckDB that exists today stays MIT forever, and anyone can fork it.

So if your risk model was "they will pull an Elastic," you can mostly put that down. The Foundation would have to be captured first, and Amazon explicitly did not buy it.

The exposure is somewhere less dramatic. It is attention.

What an acquisition actually transfers

When a company acquires a small open source team, what moves is not the license, it is the maintainers' calendar. The people who were spending Tuesday triaging a Parquet edge case now have an employer with quarterly goals, an internal customer, and an analytics roadmap that the acquisition press release names directly: making "AWS analytics faster, simpler, and more cost-effective."

That can be good. Paid maintainers who are not scrambling for consulting revenue ship more, and DuckLabs' commercial arm was small. It can also mean that the features which get attention first are the ones that make DuckDB work well inside AWS, and the ones that matter to someone running a single 8GB box in Helsinki drift down the list. Nobody has to act in bad faith for that to happen. It is just what happens when the people paying for the work change.

The other thing that moves is the support relationship. If you were paying DuckLabs for commercial support, your counterparty is now Amazon, with Amazon's contracts and Amazon's escalation paths. For most readers of this blog that is theoretical, because most of us were getting support from a GitHub issue tracker.

The check I actually run before betting on a small-team database

I have been through enough of these to have a list. It has nothing to do with reading licenses and everything to do with asking what my exit costs on a bad Tuesday.

Who holds the trademark and the repository, the company or a foundation? For DuckDB the answer is the Foundation, and that is genuinely better than most.

Can I read my data without the tool? This is the one that matters most and the one people skip. DuckDB's native format is documented, and it reads and writes Parquet, which every other engine on earth also reads. If DuckDB vanished tomorrow, my data would still be Parquet files on disk and I could point DataFusion or ClickHouse or plain Python at them. Compare that to a database whose on-disk format is undocumented and whose only export path is its own client. That is the actual lock-in question.

How many people have merge rights, and are they all at one employer? Post-close, a large share of DuckDB's core contributors will collect a paycheck from the same company. That is a real concentration, and it is worth watching even though the Foundation structure blunts it.

What does the release history look like when the project is under stress? DuckDB has shipped consistently for years. That is evidence, not a guarantee, but it is more evidence than most projects can offer.

Where this take could be wrong

The strongest argument against my caution is that this is straightforwardly good for the project. DuckLabs was a small European company monetising a database that millions of people use for free, which is a famously bad business to be in. Being inside AWS means the core team stops worrying about payroll and starts working on the database full time, with the founders still steering. Postgres got better with corporate money in it, not worse. The reasonable expectation is more releases, not fewer.

The second argument is that I am pattern matching on relicensing scandals that structurally cannot happen here, and that the Foundation is exactly the guardrail everyone said open source projects should build. It is a bit rich to spend years telling maintainers to set up neutral governance and then treat it as meaningless the first time it gets tested.

Both of those may well be right. I would rather be mildly paranoid on the day of the announcement and wrong in six months than the reverse.

What I'd actually do

Nothing this week. There is no action to take, and "nothing changes for DuckDB users" is accurate today.

What I would do is write down, once, what my escape hatch is. For me that is one line: my analytics data is Parquet on disk and DuckDB is the query engine pointed at it, not the storage layer. If that stays true, the acquisition is somebody else's news story. If you have been letting DuckDB own your only copy of anything, in its native format, with no Parquet export in your pipeline, then this is a good week to add that export step. Not because Amazon will do something, but because the general rule holds regardless: keep the format independent of the engine, and every acquisition announcement becomes a thing you read over coffee instead of a thing you have to respond to.

The thing to actually watch is the release notes twelve months from now. If the interesting new work is all about S3, Iceberg, and Glue integration, that tells you where the calendar went.

Author

Lukas

@lukcombinator

Sources

• AWS to acquire DuckLabs, the Amsterdam-based company behind DuckDB
• AWS buys DuckLabs to bring DuckDB's embeddable analytics to more enterprises
• Amazon acquires DuckLabs, adding the team behind DuckDB amid broader shakeup in cloud data
• AWS buys DuckLabs, the people behind the popular in-process OLAP database