TL;DR. On August 26, AWS signed a definitive agreement to acquire DuckLabs, the Amsterdam company behind DuckDB. The open source project is not part of the sale: its copyright and trademarks sit with the independent DuckDB Foundation, whose statutes keep the code MIT-licensed. That makes DuckDB the best-protected project in this year's wave of data-infrastructure absorptions, and the deal shows why the protection only goes so far. A license controls who may use the code. It says nothing about who pays the people who write it, which integrations get the fast path, or where the roadmap points next. If your stack embeds DuckDB, and more stacks do than list it, the steward of your query engine just changed.
DuckDB is the in-process analytical database that turned up everywhere over the last three years: inside Python notebooks, inside dbt pipelines, inside BI tools, inside Postgres itself through extensions. Its creators, Hannes Mühleisen and Mark Raasveldt, spun the project out of the CWI research institute and built a deliberately unusual structure around it: a commercial company for the engineering, and a separate non-profit foundation holding the intellectual property. On August 26, 2026, AWS announced it is acquiring the company, DuckLabs, with the deal expected to close as soon as next month. Terms were not disclosed. The foundation, and therefore DuckDB itself, stays where it is.
What AWS signed for, and what no one could sell it
The structure matters enough to spell out. DuckLabs, which renamed itself from DuckDB Labs in May, employs the core engineering team in Amsterdam and runs the commercial support business. The DuckDB Foundation, a Dutch non-profit, holds the project's copyright and its trademarks, including DuckDB, the DuckLake lakehouse format, and Quack, and its statutes commit the project to the MIT license. AWS's own announcement is explicit that it is not acquiring the open source project, and that Mühleisen and Raasveldt will continue to lead both the team and the project's technical direction after they and their colleagues become AWS employees.
So the deal transfers no code ownership, no trademark, and no relicensing power. What it transfers is everything else: the payroll of nearly every full-time maintainer, the commercial relationships, and the institutional home of the project's day-to-day priorities.
The split the press releases describe: the company moves, the project's legal shell stays.
The license was never the control point
Nobody needed to buy DuckDB to use it, embed it, or fork it. MIT gives all of that away. The assets that actually steer an open source project are narrower and none of them appear in a license text.
Where the maintainer-months go. AWS and DuckLabs have been collaborating since early 2025, when DuckDB support landed in Amazon S3 Tables and SageMaker Lakehouse, and AWS says the plan is to optimize DuckDB execution natively against S3 and its analytics services. None of that is sinister, and all of it is directional: when the maintainers' employer sells one particular object store, the question of which storage backend gets the next fast path stops being neutral.
The distribution channel. A large share of DuckDB's functionality ships as extensions that clients install at runtime from the project's default repository. Whoever operates the build and signing pipeline for that channel decides what an ordinary INSTALL reaches. That pipeline is run by the people, not the foundation's statutes.
The release cadence. Which versions become long-term-support releases, and how long they stay supported, is a maintainer decision that every downstream embedder inherits.
The adjacent specs. DuckLake, the team's lakehouse table format, is young enough that its evolution is wherever the team is. The trademark stays with the foundation; the editorial pen moves to Seattle.
MotherDuck's CEO Jordan Tigani, whose company builds its serverless product on DuckDB, described the dynamic candidly in his response to the deal: Amazon's historical playbook is to wait until an open source project gets big enough, then launch it as a service, and he expects exactly that here. He also called the acquisition good for DuckDB, arguing that Amazon now has a financial reason to keep the project open and healthy. Both halves can be true at once. That is what stewardship by an interested party means.
The best-protected project in the wave still moved
This is the third distinct shape the absorption of independent data infrastructure has taken in eighteen months. Databricks bought Neon whole, product and team together, and Neon's serverless Postgres now evolves inside a lakehouse vendor. OpenAI took the InstantDB team and left the product behind with a migration guide, a shape we examined when it happened last week. AWS has now executed the third variant: acquire the company while the project sits in a legal structure nobody can buy.
Read in sequence, the variants are converging on something. Each iteration leaves more of the open source artifact formally intact, and each moves the same underlying asset, the people who decide what the artifact becomes. The acquirers have learned to route around open source governance instead of fighting it. A foundation with binding statutes turned out to be an answer to the Redis question, who can take the license away, and no answer at all to the quieter question of who sets the agenda. A foundation holds the code; payroll steers it.
For buyers of the absorbed layers the lesson from the earlier deals carries over unchanged: continuity of the artifact is not continuity of the trajectory. Postgres users did not lose Neon's code when Databricks bought it, and the governance surface that came bundled with Lakebase still reshaped what the product optimizes for within a year.
MotherDuck's response is a hedge, not a victory lap
MotherDuck is the company most exposed to this deal that is not party to it. It builds a commercial serverless analytics service on DuckDB, it depends on an engine whose maintainers now work for a competitor of its own product, and its public response did two things at once. Tigani welcomed the deal, saying Amazon putting its weight behind DuckDB "is going to add a ton of momentum and strengthen the ecosystem." And in the same breath, MotherDuck announced it now offers enterprise support for open source DuckDB, something it had previously left to DuckLabs, taken up, in its words, with the explicit blessing of the founders.
That second move is the informative one. The vendor closest to the engine looked at the new ownership structure and immediately built a support relationship with the community that does not route through the acquired company. Teams with DuckDB in production should read that as a template rather than as reassurance.
Find the ducks in your stack before the close
The reason this deal deserves a dependency audit rather than a shrug is that DuckDB's whole distribution model hides it. It is an in-process library. It arrives as a transitive dependency, a bundled engine, a default backend, and it rarely appears on an architecture diagram. DuckDB's own adoption post reported almost 25 million monthly downloads on PyPI last October, and very few of those installs belong to anything anyone calls "a DuckDB deployment."
Concretely, for a Postgres-centered stack, the engine is likely present in more places than the inventory says:
- Inside Postgres itself. The pg_duckdb extension, built with Hydra and MotherDuck, embeds DuckDB's vectorized engine in Postgres 14 through 18 and reads Parquet, Iceberg, and Delta straight from object storage. If you run it, your operational database now contains a query engine whose steward is AWS, whichever cloud the Postgres itself runs in. The same boundary question we mapped in LTAP vs HTAP applies: the analytical side of a hybrid system carries its own dependencies.
- In the pipeline layer. dbt projects use DuckDB as a local execution backend, and data teams lean on it for pre-warehouse transformation exactly because it costs nothing to run.
- In BI and notebooks. Major BI and notebook tools ship native DuckDB connectors, and the WASM build puts the engine inside browser dashboards.
- Under AI agents. Agent frameworks reach for DuckDB as scratch space for exploratory analytics over files, which is precisely the workload AWS named when it pointed at agentic use cases in its announcement.
The audit itself is modest: grep lockfiles and requirements for the dependency, check whether pg_duckdb is installed anywhere, note which tools embed the engine, pin the versions you run, and know which extension repository your deployments pull from. Then watch the first few post-close releases with one question in mind: where does the performance work land? Nothing about this deal predicts a bad outcome for DuckDB, and the project has more funded engineering behind it today than at any point in its history. The point of the audit is narrower. A component this widely embedded changed stewards, and stacks that never wrote "DuckDB" in an architecture doc should at least know where they are now downstream of AWS's priorities.
Where Datapace fits
Datapace is building the context layer between your databases and your AI: the resolved meaning of your schemas, validated by the people who own the data, the workload evidence beside it (cost, performance, usage and freshness, lineage), and a policy gate over what an agent may do and access, served to agents over MCP. An embedded query engine is part of that estate whether or not it made the architecture diagram, and this week is a reminder that the parts nobody wrote down are the ones that change owners quietly: knowing which engines your pipelines and agents actually execute on is metadata, and it belongs in the same governed graph as the tables those engines read. If you are working out what your own stack silently depends on before the next steward changes, book a call.
Sources
- Amazon, AWS to acquire DuckLabs, the Amsterdam-based company behind DuckDB, August 26, 2026 (definitive agreement, open source project not acquired, founders' roles).
- AWS Big Data Blog, AWS and DuckLabs: Building the future of analytics together, August 2026 (integration plans, S3 and SageMaker Lakehouse collaboration).
- GeekWire, Amazon to acquire DuckLabs, adding the team behind DuckDB amid broader shakeup in cloud data, August 26, 2026 (close timing, terms undisclosed).
- SiliconANGLE, AWS buys DuckLabs to bring DuckDB's embeddable analytics to more enterprises, August 26, 2026 (2025 collaboration history).
- The Register, AWS buys DuckLabs, the people behind the popular in-process OLAP database, August 26, 2026.
- MotherDuck, DuckDB outgrows its nest, August 2026 (Tigani quotes, enterprise support announcement).
- DuckLabs, DuckDB Labs becomes DuckLabs, May 27, 2026 (rename, company and foundation structure).
- DuckDB, Adoption metrics and benchmark results for DuckDB v1.4 LTS, October 9, 2025 (PyPI download figures).
- pg_duckdb on GitHub (Postgres 14 to 18 support, Hydra and MotherDuck collaboration, object storage formats).