Amazon acquires DuckLabs and brings DuckDB inside Aurora PostgreSQL

Amazon acquires the company behind DuckDB

Amazon announced on October 17, 2026 the acquisition of DuckLabs, an Amsterdam-based company responsible for DuckDB, an analytical database that runs embedded (in-process) and became known for fast queries over Parquet and CSV files without requiring a dedicated server, according to InfoQ.

Hannes Mühleisen and Mark Raasveldt, creators of DuckDB and co-founders of DuckLabs, remain at the head of the team and technical direction of the open-source project, now as part of AWS. On the company's blog, the two explain the decision:

Joining AWS gives us the resources and reach to bring this technology to many more developers and organizations, and to pursue ideas at a scale that would have been difficult for us to reach alone.

Hannes Mühleisen and Mark Raasveldt, co-founders of DuckLabs

All components of the Duck Stack (DuckDB, DuckLake, and Quack) remain free and under the MIT license. The DuckDB Foundation, a non-profit entity, continues overseeing the projects, which was used to reassure the community about the future of the open-source work.

Why AWS wanted DuckDB

Mai-Lan Tomsen Bukovec, AWS vice president of technology, explained in the announcement the reason for the company's interest in the project:

DuckDB set out to solve the problem of blazingly fast performance for the 90%+ of data queries in the world today, that often runs 1 terabyte of data or less as part of analysis and dashboarding.

Mai-Lan Tomsen Bukovec, AWS vice president of technology

According to her, these optimizations are particularly relevant for agentic AI workloads: agents often inspect data and run small exploratory queries before deciding how to proceed, a pattern for which DuckDB is already naturally optimized.

From technical collaboration to acquisition

In a post published on the blog of Werner Vogels, Amazon's CTO, Andy Warfield, an AWS distinguished engineer, described how the relationship between AWS and DuckLabs matured before the acquisition. The first contact happened when the S3 team was working on S3 Tables, and the collaboration grew from there.

Over the past two years (give or take), our teams have worked more and more closely together and have broadened the areas where we've collaborated. We explored AWS Lambda as a matched primitive for launching DuckDB queries quickly, and we smoothed the integrations between DuckDB and the AWS database and analytics engines through DuckDB's evolving ATTACH and CONNECT commands.

Andy Warfield, AWS distinguished engineer

For Warfield, the deal is a way to broaden the founders' reach, not to absorb their work:

Hannes and Mark's vision is so aligned with the way that we think about data at Amazon that we wanted to give them the broadest possible opportunity to set the agenda not just for DuckDB, but for how analytics should be built and delivered in the cloud. So, after many conversations [...], we jointly made the decision to have the DuckLabs team join AWS.

Andy Warfield, AWS distinguished engineer

What changes in Aurora PostgreSQL

Aurora PostgreSQL is the first AWS service to receive an end-user-facing feature built with DuckDB. Esra Kayabali, AWS principal solutions architect, described the problem the integration addresses:

Previously, if your application needed to combine recent transactional data in Aurora with historical records stored in Amazon S3, a common approach was to build reverse ETL pipelines that duplicated data, increased infrastructure costs, and required ongoing engineering effort to keep everything synchronized.

Esra Kayabali, AWS principal solutions architect

With DuckDB embedded, a single SQL query in Aurora PostgreSQL combines live operational data with historical data stored in Apache Iceberg tables managed by AWS Glue Data Catalog, as well as Parquet and Iceberg files stored in Amazon S3 and S3 Tables. All processing happens within Aurora itself, without extra network hops or ETL pipelines to maintain.

In practice, this eliminates a class of infrastructure that data teams usually build by hand: scheduled jobs, queues, Lambda functions, or orchestrators like Airflow just to copy data from the transactional database to a data lake and then join everything back together in an analytical query.

The feature is available in all AWS commercial regions and in AWS GovCloud (US) at no additional cost; the customer pays only for Aurora's incremental compute consumption and the S3 requests generated by the queries.

Why this matters for those running Aurora in Brazil

Aurora PostgreSQL is one of the most common managed options among Brazilian companies running transactional workloads on AWS, from fintechs to marketplaces. Until now, combining this database with analytics over large historical volumes usually meant replicating data to a data warehouse or lakehouse via ETL tools, with all the maintenance cost that implies.

The promise of the integration is to reduce this friction: the analytical query runs within Aurora itself, touching S3 data directly, without requiring a separate synchronization pipeline. For teams without a dedicated data team, this can mean dashboards that combine recent and historical data without maintaining additional infrastructure.

What's still open

InfoQ doesn't detail performance limits of the integration nor compare the response time of federated queries with that of a traditional ETL pipeline. There is also no announcement so far that the feature will reach other AWS services besides Aurora PostgreSQL, although Warfield's account suggests the technical collaboration between the teams already reached other areas before the acquisition.

The community's reaction, recorded by InfoQ from a comment on Reddit, mixes celebration and caution:

I hope this doesn't slow the pace of innovation they have been doing, but i'm glad they found a way to both cash in on their work yet keep most of it oss under the foundation.

adappergentlefolk, Reddit user