What Amazon buying DuckDB's makers means for Aurora users

Amazon has acquired DuckLabs, the Amsterdam-based company behind the analytical database DuckDB, InfoQ reports. The first product result is already live. According to InfoQ, Amazon Aurora PostgreSQL can now use DuckDB to run a single query across your live database rows and historical data stored in Amazon S3. The processing happens inside Aurora, and there is no extra fee: you pay only for the additional Aurora compute and the S3 requests those queries generate. That pricing and placement decides whether this story touches your bills and your pipelines.

The background you need

Databases do two broadly different jobs.

Transactional work, often called OLTP, is many small reads and writes: insert an order, update a user, fetch one profile. PostgreSQL is built for this. It stores each row’s fields together, so grabbing or changing one record is fast.

Analytical work, often called OLAP, is the opposite. You scan millions of rows but only a few columns, as in total revenue by month for the last three years. Engines built for this store each column together. They read only the columns a query needs and process values in large batches. Running that kind of query on a row store works, but it is usually slow and expensive.

DuckDB is an open-source analytical database with that column-oriented design. Unlike most databases, it is built to run in-process. It lives inside another program instead of running as a separate server you connect to. People often describe it as SQLite for analytics. According to InfoQ, its creators are Hannes Mühleisen and Mark Raasveldt, who co-founded DuckLabs. A non-profit, the DuckDB Foundation, oversees the project.

Aurora PostgreSQL is AWS’s managed database service that is compatible with PostgreSQL. Your app talks to it like normal Postgres.

Some data lake vocabulary appears in the report without definitions:

• Amazon S3 is object storage. Many teams move older data there because it is cheap to keep.
• Parquet is a columnar file format, the on-disk version of the column-oriented idea above.
• Apache Iceberg is a table format. It adds a metadata layer over a pile of Parquet files so they behave like one table, with a schema and a history of changes.
• AWS Glue Data Catalog is a registry that records which tables exist and where their files live.
• S3 Tables is an S3 offering designed specifically for storing Iceberg tables.

Finally, ETL (extract, transform, load) means copying data out of your app database into an analytics store. Reverse ETL goes the other way: it pushes data from the analytics side back into operational systems. According to InfoQ, AWS principal solutions architect Esra Kayabali describes the old approach this way: teams that needed recent Aurora data and historical S3 data together often built reverse ETL pipelines. Those pipelines duplicated data, raised infrastructure costs, and needed ongoing work to stay in sync.

Here is an analogy. Your current stock list sits at the shop counter and your archive sits in a warehouse across town. To answer a question that spans both, you used to pay a courier to keep copying boxes back to the counter. Now the clerk at the counter can read the warehouse shelves directly. The analogy breaks in two places. First, the clerk is still the same person, so the reading uses Aurora’s own compute and is not free labor. Second, nothing gets copied, so the archive is only as current as whatever you have already written to S3.

What actually changed

These parts are new, according to InfoQ:

• The acquisition. DuckLabs joins AWS. Mühleisen and Raasveldt will continue to lead the team and the open-source project’s technical direction.
• A DuckDB-powered feature in Aurora PostgreSQL. One query can combine live operational data with Iceberg tables managed through AWS Glue Data Catalog, plus Parquet and Iceberg data in S3 and S3 Tables. InfoQ says processing stays within Aurora, without additional network hops or ETL pipelines.
• Availability and price. The feature is in all commercial regions and AWS GovCloud (US) at no additional charge. You pay for the incremental Aurora compute and S3 requests your queries create.

These parts were already true and stay true:

• The license. DuckDB and the rest of what DuckLabs calls its Duck Stack, including DuckLake and Quack, remain free and open source under the MIT license. The DuckDB Foundation keeps supervising the projects.
• The relationship. It is not new. In a post on Werner Vogels’s blog, AWS distinguished engineer Andy Warfield writes that contact began while the S3 team was building S3 Tables. He says the teams collaborated for roughly two years, exploring AWS Lambda as a way to launch DuckDB queries quickly. They also smoothed integrations with AWS services through DuckDB’s ATTACH and CONNECT commands.

So DuckDB could already reach AWS data from the outside. What changed is that DuckDB now runs inside a managed AWS database as a feature you can use from Postgres.

What it means if you deploy and run apps

The lever is simple. The analytical work now runs on your Aurora compute, and AWS charges no separate fee for the feature. That changes where your cost and risk sit.

Pipelines you might delete. You may run a scheduled job that copies S3 history into Postgres tables just so you can join it with live data. That job is now a candidate for retirement. You would stop maintaining sync code and stop storing the same data twice. Test with your real queries before you remove anything.

Costs move, they do not vanish. The pipeline’s compute and duplicate storage go away. In their place you pay Aurora compute for each analytical query, plus S3 request charges. Analytical scans can be heavy. S3 request counts also tend to grow with the number of files a query touches, so data split into many small files can cost more to read.

Watch your database load. These queries run in the same service that serves your app. Before you point dashboards or reports at your primary instance, check the AWS documentation for where these queries can run. Then watch CPU and latency while you test.

If you use DuckDB on its own, in scripts, notebooks, or CI, InfoQ reports that the license and foundation oversight stay as they were. Community reaction was positive but cautious. One Reddit commenter quoted by InfoQ wrote: “I hope this doesn’t slow the pace of innovation they have been doing”. Release pace is worth watching.

AWS’s broader pitch is about data size and AI agents. AWS technology VP Mai-Lan Tomsen Bukovec argues that DuckDB targets the majority of queries, which she says often run on 1 terabyte of data or less. She also argues that it suits AI agents that run many small exploratory queries. That is AWS’s framing, not an independent measurement.

What to watch next: InfoQ calls Aurora PostgreSQL the first service to get a user-facing DuckDB feature. Expect announcements for other AWS services, though the report names none.

What we don’t know yet

• The deal terms. InfoQ’s report does not give a price or financial terms.
• Performance. The report includes no benchmarks for Aurora with DuckDB against a pipeline or a separate warehouse.
• The details of use. The report does not say how you enable the feature, which Aurora PostgreSQL versions support it, or whether it can write to Iceberg tables as well as read them.
• Isolation. It is unclear how analytical queries are kept from slowing transactional traffic on the same cluster.
• Other engines. The report mentions only Aurora PostgreSQL. It says nothing about Aurora MySQL or standard RDS for PostgreSQL.
• Long-term direction. The current assurances cover licensing and foundation oversight. How AWS priorities will shape DuckDB’s roadmap over time is still an open question.