AWS buys the DuckDB company: what to price into an embedded dependency

The license is the part that cannot be clawed back. DuckDB, DuckLake and Quack are MIT-licensed, and AWS says they will stay free under those licenses ^[5]. Code already shipped stays shipped, so a fork is legally available from the day the deal closes. What a buyer gets instead is everything that makes forking unattractive: the maintainers who know the engine, and with them release engineering and bug triage ^[6].

The dependency is unusual because of where it sits. DuckDB runs inside the application rather than behind a connection string, which is why the SQLite comparison keeps getting made ^[3]. At three million downloads a day, DuckLabs' own high-water figure ^[4], that is on the order of a billion pulls a year ^[13]. If your product compiles DuckDB in, replacing it later means changing shipped client code and every query written against its dialect. That is not a migration you schedule for a quiet week.

Two governance details in the announcement carry more weight than the reassurance around them. AWS will fund a technical advisory board inside the DuckDB Foundation to collect community feedback on the roadmap ^[11], and it will open the extension ecosystem to signed third-party extensions ^[12]. Advisory boards advise. Signing implies a signer, and the account of the deal does not say who holds the keys or who can decline to use them. For anyone shipping a build that loads extensions, that is worth an answer before close rather than after.

Then there is the money. DuckLabs funded itself by selling commercial support and feature development to open-source users, and after the deal it no longer needs to, because AWS provides the funds ^[10]. Whatever you think of the old model, it put a price on the roadmap: a company that wanted a feature could buy engineering time. That channel is being retired and the replacement is a forum. The remaining payer has stated preferences. The collaboration started in early 2025 with DuckDB support in Amazon S3 Tables and SageMaker Lakehouse ^[8], and Andy Warfield, an AWS vice president and distinguished engineer, gave as his reason that DuckDB is "broadly used and very much loved by S3 customers today" ^[9]. Hannes Muhleisen, for his part, points to users who may "eventually rely on the Duck Stack without needing to operate a database themselves" ^[14], which describes a service rather than a library.

None of this requires anyone to act in bad faith to cost you something. The risk to price is ordering: work that makes DuckDB better against S3 landing ahead of parity for other object stores, with the Foundation still named as steward ^[7] and the payroll elsewhere.