By ByteBot
AWS closed its acquisition of DuckLabs — the roughly 30-person Amsterdam team behind DuckDB — in early September 2026. The MIT license is unchanged. The DuckDB Foundation still governs the project. What changed is this: two of the Foundation’s three board members now collect Amazon paychecks, and the board’s own charter lets those members appoint their successors without any community vote. DuckDB 2.0 drops on October 21 as the first major release under that arrangement.
MIT Is a Floor, Not a Plan
AWS didn’t buy DuckDB the way Oracle bought MySQL — it bought the people. The open-source project stays MIT-licensed, the Foundation’s deed stays in place, and Hannes Mühleisen and Mark Raasveldt are publicly committed to its independence. The uncomfortable reality, however, is structural: a majority of the Foundation’s board now works for the acquirer, and the Foundation’s own governance rules allow that majority to control future board appointments indefinitely.
The pattern here is not new. AWS spent years being publicly shamed for “strip-mining” Elasticsearch — taking the code, building a managed service, and contributing little back. Elastic eventually relicensed under BSL. When Redis moved to the Commons Clause, AWS backed the Valkey fork. The lesson AWS drew from both episodes: buy the maintainers before any conflict starts. “MIT is a floor, not a plan,” as one governance analysis put it. “Paychecks bend roadmaps, whatever the governance charter says.”
That framing matters because evidence of roadmap influence already exists. AWS-sponsored work on S3 integration and Iceberg extensions — both aligned with AWS S3 Tables — shipped in the months preceding the announcement. The AWS announcement blog promises to “make DuckDB applications run best on AWS” and “integrate DuckDB’s performance and simplicity in our other AWS services.” That’s not a neutrality statement — it’s a product roadmap.
DuckDB 2.0 Drops October 21 — Breaking Changes Are Real
Regardless of governance concerns, DuckDB 2.0 ships in ten days and developers need to prepare. Python 3.9 support is dropped — the minimum is now Python 3.10. Module paths change: duckdb.typing becomes duckdb.sqltypes, and duckdb.functional becomes duckdb.func. Single-arrow lambda syntax (x -> x*2) is disabled by default. Arrow methods are renamed. The new default storage format is incompatible with v1.x — databases created in v2.0 cannot be read by older installs.
Migration issues are already surfacing in GitHub. If you haven’t tested against the alpha builds, do it now. The DuckDB 2.0 highlights preview documents the full change list, but the storage format incompatibility is the one that hurts most — there’s no clean rollback once you’ve written data in the new format.
Related: DuckDB 2.0 Drops October 21: Client/Server, Breaking Changes
The Architecture Shift: “No Server” Is Dead
DuckDB’s defining characteristic was its simplicity: no server, no configuration, just an embedded analytics engine that ran in-process. Version 2.0 abandons that. The new quack extension enables any DuckDB instance to run as a network daemon accepting connections from multiple clients. The new CONNECT statement attaches remote databases. Asynchronous I/O throughout the engine delivers up to 40x speedups for network storage workloads.
The timing is hard to ignore. DuckDB 2.0’s server mode shipped nine days before the AWS deal was announced. A client/server protocol is exactly what AWS needs to offer DuckDB as a managed cloud service — and now they own the engineers who built it. This doesn’t prove coordination, but it removes the coincidence defense. The architecture change, the acquisition, and the upcoming release form a coherent commercial strategy, whether it was planned that way or not.
MotherDuck’s Dilemma
MotherDuck raised roughly $100 million building “DuckDB in the cloud” — hosted DuckDB running on AWS infrastructure. Their entire business now competes with their database provider’s corporate parent. CEO Jordan Tigani is publicly optimistic, writing that “a rising tide lifts all Ducks”, and drawing parallels to how Snowflake thrived despite Redshift. He acknowledged the response “could look hopelessly naive in retrospect.”
That qualifier is doing a lot of work. MotherDuck now openly offers enterprise DuckDB support — a market they previously avoided to prevent competing with DuckLabs. Three of their engineers are among DuckDB’s top external contributors. They’re betting on coexistence, but the Redshift comparison actually cuts the other way: Amazon built Redshift after partnering with Snowflake. The playbook exists. Whether AWS uses it here is the open question.
Key Takeaways
- AWS acquired DuckLabs in September 2026; the MIT license is unchanged, but two of three DuckDB Foundation board members now work for Amazon — governance risk is structural, not theoretical
- DuckDB 2.0 ships October 21 with real breaking changes: Python 3.9 dropped, module paths renamed, lambda syntax disabled by default, new incompatible storage format
- The v2.0 client/server mode arrived nine days before the acquisition announcement — timing that maps cleanly to AWS’s managed service ambitions
- MotherDuck faces real uncertainty as a DuckDB-in-cloud startup now competing with its database provider’s new owner
- Apache Datafusion is the community-recommended alternative for teams that need embedded analytics without single-company dependency
