On August 26, AWS announced it signed a definitive agreement to acquire DuckLabs, the Amsterdam company behind DuckDB. The deal is expected to close in early September.
Arc embeds DuckDB as its query engine, so I read both announcements more carefully than most people will. The headlines circulating today are mostly wrong in the same way, and the part that actually matters is not the part being reported.
What AWS actually acquired
AWS acquired DuckLabs, the company. It did not acquire DuckDB, the project. Amazon states this outright: "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."
Peter Boncz, who sits on the DuckDB Foundation board representing CWI Amsterdam, was more specific: the Foundation "holds all IP of open-source DuckDB, and will continue to do so."
So the structure is a company acquisition with the intellectual property sitting outside the acquirer, in a nonprofit, under MIT. The roughly 30 person team stays in Amsterdam. Hannes Mühleisen and Mark Raasveldt continue leading the project's technical direction. Community support limits are being lifted rather than tightened.
If you build on DuckDB, nothing in your license changed today. MIT is irrevocable on code already released. Nobody can take that back, and the entity holding the IP is not the entity that was purchased.
The part of the announcement worth reading twice
The DuckLabs announcement runs to about ten minutes. Most of the coverage will quote the first paragraph. The interesting material is in the middle, where they explain why they sold.
DuckLabs was bootstrapped. They say so plainly: when DuckDB started gaining momentum and venture capital firms were calling, they chose "a bootstrapped company, fully owned by its founders and development team." That decision held for five years while they grew to more than thirty people and DuckDB reached more than a million downloads per day.
Then this:
"As founders, we worried that DuckDB's growth would eventually outpace our ability to support it. That our small company could become a bottleneck for the project, the team, and the people building businesses on top of it. We also worried that scaling DuckLabs into a much larger sales, support, and operations organization would pull our attention away from the technical work and open-source community that made DuckDB successful in the first place."
And then the sentence I have not been able to stop thinking about:
"Our partnerships work best with highly technical organizations, often companies with substantial database expertise of their own. Reaching a much broader group of users requires us to solve more complete and specialized problems, serve the needs of different industries, invest substantially more in infrastructure, and reach people who may never think to seek out an analytical database directly."
That is the most honest description of the open source database business I have read from anyone actually running one.
Why that sentence matters to me
I run a bootstrapped database company. It is much smaller than DuckLabs was. Arc is open source, it has an enterprise tier, and it runs in production in aerospace, healthcare, logistics, and manufacturing.
The pattern DuckLabs describes is the pattern I live. The commercial conversations that work are with sophisticated technical buyers who found the project themselves and already understand what they need. Our first enterprise customer found us through GitHub and closed in three months without a single cold email. Everything we tried in the other direction, outbound lists, sequences, an SDR, produced nothing at all.
The gap between "many people use this" and "some people pay for this" is not a marketing problem you can fix with better copy. It is structural. It is the shape of the business.
I had assumed that gap closed with scale. That at some level of adoption the funnel simply works, and my version of the problem was a symptom of being early and small and alone.
DuckLabs had a million downloads a day, thirty engineers, five profitable years, and enough leverage to turn down venture capital. They looked at the same gap and concluded they could not cross it as an independent company. Not because the technology was insufficient. Because reaching past technically sophisticated buyers required infrastructure, industry-specific work, and distribution reach they could not build alone.
That is not a discouraging conclusion. It is a clarifying one. Distribution is the constraint in this business, and it is the constraint at every scale, including scales I have never operated at.
The AWS reversal nobody is mentioning
There is a piece of history that makes this deal more interesting than it looks.
In January 2021, Elastic changed the Elasticsearch license from Apache 2.0 to a dual SSPL and Elastic License model, explicitly to stop cloud providers from monetizing the project without contributing back. AWS responded by forking the last Apache-licensed release and creating OpenSearch, which it later transferred to the Linux Foundation.
That was the old playbook. A vendor restricts the license to defend against the hyperscaler, and the hyperscaler forks around them.
Five years later the same company is doing something different: acquiring the team, leaving the IP with an independent foundation, and publicly committing to MIT. Whether that commitment holds over a decade is a question nobody can answer today. But the structure they chose is meaningfully better for the ecosystem than the structure they chose in 2021, and that is worth saying plainly.
What changes if you build on DuckDB
Practically, three things are worth tracking.
Roadmap priorities will drift. Not through bad faith. The people setting DuckDB's technical direction now work for AWS, and Amazon's own framing is that together they will "make AWS analytics faster, simpler, and more cost-effective." Over a few years, features that serve that goal will naturally rank above features that serve a niche embedder. That is gravity, not malice, and it is the honest risk of building on someone else's engine regardless of who owns the company.
The extension stack is opening. DuckLabs says they plan to allow extensions signed by other developers and organizations to run in DuckDB. If that ships as described, it materially reduces the risk above. Needing something upstream does not prioritize becomes a thing you can ship yourself rather than a thing you wait for.
The Foundation is adding a technical advisory board so community members can input on direction. How much influence that carries in practice is the open question, and it is the one I would watch most closely, because it is the mechanism that determines whether the community's voice survives contact with a corporate owner.
There is also a structural reason this is less exposure than it sounds for Arc specifically. DuckDB is the query engine, not the storage layer. Arc writes standard Parquet files that any engine can read, which means the data stays portable regardless of what happens upstream. An engine is replaceable when the format underneath it is open. That was true last week and it is still true today, which is most of the reason today is a normal day.
What I take from it
The near-term answer for anyone building on DuckDB is that today is a normal day. MIT holds, the Foundation holds the IP, the team is intact, and the project has more resources than it had last week.
The longer answer is that this is the fourth time this year that a company far larger than mine has arrived at a position I bet on early. Elastic conceded that columnar storage is the correct architecture for large-scale reads. InfluxDB rebuilt its storage engine on Parquet. QuestDB rebuilt its wire protocol. Now the largest cloud provider in the world paid to bring the team behind the leading embedded columnar engine in house.
Being early to a correct architectural bet is worth something. It is worth considerably less than distribution. DuckLabs, at a scale I may never reach, decided that trade explicitly and in public, and I think they were honest about why.
Arc is an open source time-series database for telemetry you need to keep. Open Parquet storage, standard SQL, single binary, no vendor lock-in at any layer. See how Arc compares or read the code on GitHub.