DuckLabs, the company behind the beloved developer database DuckDB, is being acquired by Amazon Web Services (AWS). The August 26, 2026 announcement stated DuckLabs will join AWS as a subsidiary in September 2026. There are no planned changes to the MIT license and the company’s open source IP will continue to be held by the DuckDB Foundation.

Between its investment in Valkey and its donation of OpenSearch to the Linux Foundation, AWS has proven itself a good steward of open source database projects of late, so I’m cautiously optimistic about what this means for DuckDB’s next chapter. But it’s worth understanding what AWS actually bought and why a database that made its name running on laptops is worth a hyperscaler’s money.

DuckDB and the Forces Behind It

DuckDB was first released in 2019, out of the CWI research lab in the Netherlands (the same lab that helped pioneer vectorized execution with MonetDB and X100). In the intervening years, DuckDB has exploded in popularity with developers, driven by strategic choices from the team and accelerated by broader industry trends.

Engine and Form Factor

DuckDB is an analytics engine that runs as a library.

Let’s unpack both halves of that statement.

First, the engine is columnar and vectorized. This is true of Snowflake, ClickHouse, Photon (Databricks), Redshift and BigQuery. Vectorized columnar is honestly table stakes for anything supporting analytics workloads, so maybe this doesn’t seem very differentiated.

What’s different is the optimization. Competitors scale by adding machines, whereas DuckDB parallelizes within the boundary of the machine. That sounds like a constraint until you realize how far the boundary of the machine has moved; a single cloud instance (or in fact a single laptop) today can pack so much compute power.

The second half of the differentiation is the “as a library” form factor. DuckDB (like SQLite) installs like a package either with a single command via the CLI or as a dependency in your manifest. This works because the team deliberately kept it free of external dependencies, which means it runs essentially as an embeddable library. There are no servers to run, no daemons to supervise, and no connection strings to manage.

This means DuckDB is designed to go anywhere your code goes. When you combine that library form factor with per-core efficiency, many of DuckDB’s initial destinations were developer laptops.

Market Forces

The above decisions were product design choices made by the team. At the same time, there were market-wide trends supporting this approach.

The disaggregation of compute and storage combined with the rise of open table formats (namely Iceberg but also Delta Lake) means that the database engine no longer has to own the bytes it queries.

Add in AI interfaces (especially AI products promising natural-language-to-SQL query translation and MCP server access) and you see that the method of accessing data is structurally shifting.

Storage, query engine, and user interface all used to ship as a single database product. That’s unraveling.

DuckDB is an example of what the query layer looks like when it’s pulled apart from the rest.

Why?

From DuckLabs’ perspective, this acquisition has lots of potential to scale their reach. Per the company’s blog post, “joining AWS gives the DuckLabs team an extraordinary opportunity to bring the Duck Stack to a much larger audience while continuing to invest in the open-source technology at its heart.”

The question that is more interesting is why DuckDB is a useful target for AWS, and maybe to start it’s helpful to dive into the term “Duck Stack.”

Focusing only on DuckDB sells DuckLabs’ assets short, because AWS gains access to three products with this acquisition: DuckDB, DuckLake, and Quack.

DuckLake is a lakehouse format, which reached 1.0 in April. Quack is DuckDB’s client-server protocol, which launched as a beta in May.

DuckLake

DuckLake is conceptually similar to Iceberg in that both add a metadata layer that turns files living in object storage into tables with transactions, schema evolution, and snapshots. Where it differs is the metadata storage.

Iceberg keeps its metadata in the object storage bucket, which necessitates complicated commit protocols and a separate catalog bolted on top for full table functionality. DuckLake puts the catalog and metadata in a SQL database and only has the Parquet files in object storage.

In short: Iceberg became a default standard in table formats because it’s portable and agnostic, but to use it effectively you need a catalog on top of it. DuckLake says “if you’re going to need a catalog anyway, let’s go ahead and use a database.”

Quack

Quack is a protocol that essentially allows multiple DuckDB instances to talk to each other, which expands DuckDB’s use cases beyond what the engine’s in-process architecture allows. One notable capability this opens is the ability for multiple concurrent writes. Because every Quack client is a full DuckDB database, queries can plan across local and remote tables.

It also allows devs to move the compute next to the remote data, which is likely interesting to AWS. Your laptop is a bad place to scan a terabyte sitting in S3; a cloud instance in the same region as your bucket is much better. Quack lets the database engine run in the cloud while the developer drives it remotely.

But Still: Why?

For a long time the data lake pattern has been:

• data lands in S3
• maybe the customer uses Redshift, but in many cases are connecting another provider’s query engine to their AWS bucket
• the other provider captures the relationship and the value-added margin
• AWS is paid for the storage

AWS is happy to provide primitives. The power of their platform is that users and partners have the flexibility to build what they need; if what the users want is cheap reliable object storage in S3 connected to an analytics platform like Snowflake or Databricks, AWS will happily sell the storage and let the customer build what they want.

That said, AWS really would prefer to own the workloads, too. And that’s where DuckLabs comes in.

And you might be saying to yourself, “What? How does buying a database that can run anywhere help a cloud own more workloads?” It can seem a little counterintuitive.

The narrow answer is competitive: any workload diverted from a competitor is a positive for AWS. This is especially true given how much lock in is happening at the catalog level now that table formats are open.

But that’s only part of the answer. Today’s technology ecosystem is increasingly getting abstracted. In a world where storage separates from the engine, engine breaks from the interface, and the interface increasingly dissolves into AI, it’s hard to know where to make a bet.

And a solid bet is betting on the tools developers reach for.

Owning the relationship with the developer is increasingly valuable in an era when everything about software development is changing so quickly.

And the way to reach developers is by offering them open tools with well-considered developer experience. That means a database that runs anywhere is an asset, not a liability. That asset is what AWS bought with this acquisition.

As with any acquisition, there are always risks in keeping the magic of the acquired asset alive. But the promises made around relatively independent operations and keeping the IP open alleviate some of the concerns. AWS has made important strides in recent years trying to build stronger relationships with developers, in being a conscientious open source citizen, and in focusing on developer experience, which alleviate more.

For all the reasons laid out above, structurally it makes sense for AWS to foster this open developer ecosystem. At the same time, there are existing competing products in the AWS portfolio, like Redshift and S3 Tables, that are also in play. AWS has a strong history in allowing multiple solutions to exist simultaneously, but the success of the acquisition will be judged in comparative engineering investment across these solutions 18 months from now.

---

Related Posts:

• The Disintermediation of Databases
• How Apache Parquet Uses Dictionary Encoding and Snappy Compression for Efficient Storage
• Two Years of Valkey

Disclaimer: AWS and Google (BigQuery) are RedMonk clients.