DuckDB 2.0.0 LTS “Cinnamon Teal”
duckdb.org
duckdb.org
Still don't usually see a speedup past about 192vCPU, but prior to 2.0, speed would top out at more like 64vCPU, so this is a big win.
That has enabled us to scale Splink (FOSS record linakge software) to process 1bn records with 10bn record comparisons in 10 mins, which as far as I'm aware makes it the fastest linkage engine of this kind. Most of this performance comes from simply delegating the big calculations to the DuckDB engine! https://moj-analytical-services.github.io/splink/topic_guide...
Thanks to the team for all their work!
Do you find that with the performance of duckdb, you see large deployments of spark based workflows less often? It seems hard to justify the complexity of spark if you can use duckdb , but I’m wondering if you see end users still reach for spark for any reasons?
There are a variety of people still use Spark, but this is usually due to constraints on their platform/infrastructure, not because it performs better. For instance people on Databricks can sometimes find it hard to use DuckDB on large machines, or they're just more familiar with Spark.
For a new user who has flexibility over where to run their workloads, we'd always recommend DuckDB. This is particularly the case now that: - Splink 5 (released in September) allows you to run your workload in n chunks, meaning you can distribute it across multiple machines even on DuckDB - DuckDB 2.0 parallelises better on large machines, so throwing a single massive machine at problems is now more viable
In general, after using Spark for a long time, I think for most workloads, it's just not really needed any more. Too complex, too difficult to tune. Perhaps if you have genuinely massive data. I've written a bit more about why I advise against Spark in most instances here: https://www.robinlinacre.com/recommend_duckdb/
Async io generally causes a CPU bump as a side-effect, when the bottleneck moves from the disk to the CPU (more usually memory bandwidth).
My experience is from a different SQL engine, but the improvement in scan rates directly translates all other operators getting more work to do per unit time.
More CPUs pegged at 100% is always a good sign of smooth flows, but optimizing further requires data layout changes from that point. Even if it is a sub-linear speedup out of concurrency scaling - more with more is still a win, assuming you can pay for more (the Dy-skew paper has an example I can quote).
One thing we've seen with DuckDB, which they also mention in their docs, is that it's possible to 'over parallelize'. Beyond some number of cores, the overall workflow measured in wall time actually slows down when you add more CPUs, because of the overhead of parallelizing, despite them running at 100%.
We observe this even if we pull the data from S3 onto the local SSD before processing,
Duckdb might not be the reason, the real reason might be AWS.
It's been two years since I worked on this, but AWS Nitro might be triggering a high CPU Steal % when all the cores are busy at the same time.
You can do taskset -c 1-191 <server-process> and get a tiny bit of breathing room there.
I almost always do this above 32 cores, since this lets me always have a nice responsive ssh connection when the rest of the CPUs are churning high.
The more cores you have, the less of a problem sparing 1 core becomes.
True. This is true by experience. I want to add that, additionally this is not just true based on experience, rather it is fairly a straightforward logic.
If the cpu is already saturated at 100% doing work in the most "efficient" way possible for a given data structure (some sort of a shannon limit for the given data structure), then there is zero further improvement possible.
Any additional improvement must therefore happen either on the thing that the CPUs operate on (data structure improvements) or on the hardware themselves.
I built a DuckDB extension so you can connect via Postgres wire protocol, or Arrow flight. DuckDB also has its own Quack protocol, but client support for Quack is very limited right now, whereas many data tools support Postgres wire protocol or ADBC (which you can use with Arrow Flight).
We used to use Metabase but the cloud / self hosted divide was too much fiddling, along with the expression language.
I just used DuckDB 2.0 last week to compress 7 terabytes of Azure logs (NDJSON) to 2.5% of the original size in Parquet format in under two hours with a medium sized VM!
Those logs were then small enough to run ad-hoc queries in tens of seconds directly from the archive blob storage.
I created a “frozen DuckLake” and sent the signed blob URL to the security analyst.
No need for a server, no need for Splunk!
It’s easy to use, fast, can be plopped anywhere on a network, and it’s free!
If it just had KQL syntax support, it would be perfect…
Good idea for an extension, especially with the new PEG parser.
What are you guys using it for?
* IME most companies don't actually have BIG data, but are talking about (at most) a few TB, which DuckDB is fine with.
Transparent queries on server/browser in identical sql.
If you play all the tricks Google's Capacitor does to the data layout, you can shove ~2-3 million rows to a browser based query engine in 16-20Mb with duckdb-wasm. We can scale it up to ~1Gb with HTTP range queries, with cache-control.
Then we use Jev to write SQL queries over it in 1-2s, whenever someone has a followup question. Getting Jev to write SQL takes a bit of prep, but my co-founder wrote a paper about clairvoyant query execution a few years ago [1].
I could have 3000 users logged into the same application, but all of them would be bringing their own CPU to run duckdb. My compute scaling problems for my data cube is a solved problem with this approach.
This is somewhat unavoidable if you have a number of files and a tight filter which rejects most of them. The footer choice was a bad one in hindsight (not for HDFS), but for anything which uses XOR or other kind of erasure coding. The other other file format I worked with used headers only instead of footers, to save a few ms in latency for the initial GET
I don't think Ducklake can maintain a zone-map or ART index over parquet files, but there is no equivalent of iceberg metadata/something which has min/max/HLL compacted across multiple files yet.
The secondary indexes with file identifiers stored in a sequential file is most likely the next useful thing duckdb can make.
can you please elaborate? does duckdb support querying custom storage formats?
No, this is still parquet being loaded in.
The "trick" is running through sort order combinations which result in maximum packing in a Dremel style data format (like Parquet).
Here's the trick explained in enough detail to understand, but not enough to copy as-is
https://cloud.google.com/blog/products/bigquery/inside-capac...
Search for the section with
"Capacitor builds an approximation model that takes into account all relevant factors and comes up with a reasonable solution."
or a more detailed dive in the paper (by the favourite author of performance engineers, Daniel Lemire)
we process it 'daily' convert it from csv to parquet with a little post-processing for attribution, and have a small duckdb-powered dashboard/wrapper for reporting and dynamic queries
While I'm fully aware of DataFrame, I am more familiar with SQL. So I used Python scripts in Jupyter to load Excel sheets into DuckDB, and then run queries in DuckDB. Eventually I export the data back to Excel or SQL Server.
Not the most efficient way to do this I know, but it works for me.
For bigger integrations I use it as a trino alternative. If I have to combine multiple data sources I'll walk down the DB buffet and fill my local duckdb with datasets from each source with pandas.read_sql, and then do the joins locally, and publish or push the data back out.
Sorry, does this mean that their own duckdb format already supports async or doesn't?
> Other formats, such as JSON files and DuckDB's native database format, use synchronous I/O.
For the future:
> Most of its benefit comes from accessing remote data, but cold local reads can also benefit, albeit less. Next, we plan to add async reads for JSON and DuckDB-native files, as these are the two other formats most relevant to DuckDB core. Formats that live in out-of-tree extensions are not on the roadmap yet.
Disclaimer: I'm the DuckDB developer who implemented Async I/O for parquet, csvs and the DuckDB Format.
The release announcement links to several pages from a few months ago, like:
https://duckdb.org/2026/07/31/asynchronous-io
which according to you are no longer true.
EDIT:
Today I see in the release announcement "DuckDB 2.0 introduces asynchronous I/O for reading Parquet and CSV files, as well as DuckDB's native storage format. "
So it seems that the announcement has been updated, because I am pretty sure that yesterday the ending of this sentence did not exist.
The DuckDB devs measured it ~30x faster than PostgreSQL (and ~3x faster than Arrow Flight) for bulk transfer, which pg is known to be very slow at, and a bit faster (<2x) than pg for small writes up to 8 threads, after which they say that pg continues to scale well with number of threads but DuckDB plateaus.