DuckDB just got a landlord: AWS is acquiring DuckLabs

If you have ever pointed a query at a four-gigabyte crawl export instead of waiting for a spreadsheet to open it, you have probably used DuckDB. On August 26, 2026 its founders announced that DuckLabs, the company behind it, is joining Amazon Web Services as a subsidiary, expected to be effective in early September.¹ The license and the governance both hold, which is the strong version of this kind of deal and deserves saying first. What the license does not govern is where engineering attention goes, and AWS was explicit about that in its own post.

The MIT license protects the code. It says nothing about the roadmap.

Who now owns DuckDB, and what exactly changed?

The company changed hands; the project’s terms did not. Mark Raasveldt and Hannes Muhleisen wrote that DuckLabs is joining AWS with no changes to the projects’ roadmap, licensing or governance model, and that DuckDB, DuckLake, Quack and every other extension stays free and open source under the MIT license.¹ Stewardship stays with the nonprofit DuckDB Foundation.¹

The Foundation will also set up a stakeholder advisory board able to influence project direction, and the limits on community support are being lifted.¹

Two details are worth pinning down before anyone reasons from this. The deal was announced as expected to be effective in early September, so at the time of writing it has been announced and not completed. Neither post discloses terms.

The Foundation is also not a concession invented for this announcement. It predates the deal and already held stewardship, which makes the governance reassurance stronger than a promise made at the moment of sale. The advisory board is the new part, and it did not exist when the post went up.

What does the MIT license actually protect?

The MIT license protects every line of code already released, permanently and irrevocably. Nobody can retroactively close what has shipped, relicense your existing copy, or require payment for a version you already run. If AWS reversed course entirely tomorrow, the DuckDB on your machine keeps working and anyone is free to fork the last open release.

That is a real guarantee and it covers a narrow question. A license governs the terms on which code is distributed, and it has nothing to say about what gets built next, which platform gets first-class integration, or where the maintainers’ hours go. Those are decisions an owner makes, and the owner changed.

Think of it as a lease. A lease fixes your rent and your right to stay, and it says nothing about whether the owner renovates the lobby or lets the back stairwell go. The analogy breaks on permanence, and it breaks in your favor: a lease ends, and the MIT license does not, so the copy of DuckDB already on your machine is yours for good in a way no tenancy ever is.

The distinction matters here because the two are usually announced together and then read as one. “Stays open source” answers the question of whether your current setup is safe. It does not answer whether the local, laptop-shaped path stays as good as the S3-shaped one in three years.

What is AWS saying it wants to build?

AWS stated its direction plainly. Its post says the company is “excited to make DuckDB applications run best on AWS” and will “continue to invest in deep integration between DuckDB and our building block services.”² It also describes using DuckDB inside its own infrastructure and looking at how to integrate it across other AWS data and analytics services.²

None of that is a criticism. A company acquiring a database engine and then investing in making it work well with its own storage and compute is behaving exactly as expected, and the sentence is useful precisely because AWS chose to say it out loud rather than leaving it to be inferred.

Hold both facts at once instead of letting one replace the other: the projects stay open under a foundation, and the entity now funding most of the engineering has a stated preference about where those projects should run best. In my opinion, that combination is better than most acquisitions of this kind and it still moves the center of gravity.

Do the performance numbers in the AWS post describe DuckDB?

The AWS figures describe Amazon Quick, not DuckDB on its own. AWS reports that since Quick launched in October 2025 it has processed over 2.5 billion queries using its custom Quick query engine with DuckDB integrations and optimizations, and that those integrations helped reduce Quick’s average query latency by 30 percent.²

Read the subject of those sentences carefully. The figures are about a Quick engine that includes DuckDB integrations, measured by AWS, on AWS infrastructure, against AWS’s own prior baseline. They are not a benchmark of DuckDB, they do not compare DuckDB to anything, and they tell you nothing about what the tool will do on your laptop against a crawl export.

Both sources here are parties to the deal, which is the broader limitation. Two press posts agreeing is weaker than two independent measurements agreeing, and no third-party reporting is cited in this piece because none was available at the time of writing.

What should a one-person data stack do about this?

A one-person data stack should do nothing this month about the AWS and DuckLabs deal. There is no migration to plan, no version to pin defensively and no reason to move a working pipeline off a tool whose license just got publicly reaffirmed. Acting now would mean paying a real cost against a risk nobody has evidence for yet.

The reason DuckDB earns its place in an SEO workflow is unchanged by any of this. Crawl exports, log files, Search Console bulk downloads and product feeds arrive as large delimited files that are too big for a spreadsheet and not worth standing up a warehouse for. A query engine that runs in-process is what makes that work tractable for one person. In-process means it runs inside your own script, with no separate server to stand up and no account to create. Whether the company behind it reports to Amsterdam or to Seattle does not change the file on disk.

What would change the calculus is a shift in what gets built, and that is a question you answer by watching rather than by predicting.

What should you watch over the next six months?

Two things about this deal are worth watching, both visible in public artifacts rather than in announcements. First, whether new extensions and integrations land on AWS services before or better than on local and other-cloud paths. Release notes and the extension repository show that directly, and a consistent pattern there is the earliest honest signal that attention has moved.

Second, whether the stakeholder advisory board is actually constituted, who sits on it, and whether its membership is published. The board was announced as something the Foundation will set up, so its existence and composition are a concrete commitment with a checkable outcome.

One thing not to do is forecast. A prediction about what AWS does in 2028 costs nothing to make, cannot be checked, and would be the weakest sentence in this article. The useful move is to write down what would count as evidence, then look at it in six months, which is why the two items above are phrased as observations rather than as fears.