Last Tuesday night, around 11:30 PM, my friend Derek texted me a link with zero context. Just a URL. No "hey check this out," no emoji, nothing. That is how Derek communicates — like a serial killer leaving clues.
The link was to a DuckDB blog post. A team of engineers had walked into an Apple Store, picked up the cheapest MacBook they could find — a $700 MacBook Neo with 8 gigs of RAM — and proceeded to run enterprise-grade database benchmarks on it. And the thing won.
Not "won" in the sense of "performed admirably for its price point." Won as in: it literally beat a 16-core cloud server on cold-run queries. A $700 consumer laptop outperformed a machine that costs roughly $0.55 per hour to rent on AWS.
I stared at those numbers for a good ten minutes before I texted Derek back: "This cannot be right."
What DuckDB Actually Tested
Let me back up. DuckDB — for those of you who have not fallen down the analytical database rabbit hole — is an open-source tool designed to crunch large datasets directly on your machine. Think of it as SQLite but for analytics. No server needed. No cloud account. Just you, your laptop, and a terrifying amount of data.
The DuckDB team used two industry-standard benchmarks:
ClickBench: 43 Queries on 100 Million Rows
ClickBench throws 43 aggregation and filtering queries at a single wide table containing 100 million rows. The dataset weighs about 14 GB in Parquet format or 75 GB as CSV. This is the kind of workload that, five years ago, would have required a dedicated analytics cluster.
The MacBook Neo completed all 43 queries in under 60 seconds on a cold run. Let that sink in.
TPC-DS at Scale Factor 300: 99 Queries Across 24 Tables
TPC-DS is nastier. It has 24 tables, 99 queries, window functions, complex joins — the works. At scale factor 300, you are looking at roughly 300 GB of raw data. On a machine with 8 GB of RAM.
And it still finished. Every single query.
The Numbers That Made Me Text Derek at Midnight
Here is where it gets genuinely embarrassing for cloud providers. The DuckDB team ran the same benchmarks on three machines:
- MacBook Neo — 6-core Apple A18 Pro, 8 GB RAM, $700 retail
- AWS c6a.4xlarge — 16 AMD EPYC vCPU cores, 32 GB RAM, ~$0.55/hour
- AWS c8g.metal-48xl — 192 Graviton4 vCPU cores, 384 GB RAM (the big boy)
On cold runs — the first time each query hits before anything is cached — the MacBook Neo posted a median query time of 0.57 seconds. The c6a.4xlarge? 1.34 seconds. The 192-core monster? 1.54 seconds.
Read that again. The $700 laptop was faster than both cloud instances on cold queries.
Why Cold Runs Matter More Than You Think
"Okay but hot runs are what matter in production," I can already hear some of you saying. And sure, on hot runs the c8g.metal-48xl absolutely crushes everything with a 4.35-second total versus the MacBook's 54 seconds. You are not going to replace a 192-core server with a laptop for production workloads.
But here is the thing my colleague Sandra pointed out when I showed her the data: most analytical queries in real companies are not hot-run production queries. They are ad-hoc explorations. A data analyst opening a notebook, writing a query, running it once, staring at the results, tweaking the query, running it again. Cold runs. Every single time.
For that workflow — which is probably 80% of actual data work happening in companies right now — the $700 laptop is competitive with a cloud box that has four times the RAM and ten additional CPU threads.
The Local NVMe Advantage Nobody Talks About
The reason the MacBook wins on cold runs is almost stupidly simple: local storage is fast. Cloud instances use network-attached disks (EBS on AWS), and the first read from those disks is slow. Not "slightly slower" — dramatically slower.
The MacBook Neo has an NVMe SSD soldered directly to the board. It is not even a particularly good NVMe SSD by modern standards. But it is local, and local beats network-attached on first reads every single time. This has been true for years and yet somehow we all collectively decided to pretend it did not matter.
My old roommate Marcus — who now works as a data engineer at a fintech in Austin — has been saying this for ages. "Everyone ships everything to the cloud and then complains about latency," he told me over coffee last month. "Bro, the data is literally right there on your disk. Just... use it."
I thought he was being contrarian. Turns out he was just early.
The DuckDB Secret Sauce
It is not just about the hardware, though. DuckDB does something clever: it lets you set a memory limit below your total RAM (they used 5 GB out of 8 GB), and then handles larger-than-memory workloads by intelligently spilling to disk. Most other databases would either crash, slow to a crawl, or start swapping like a desperate trader in a margin call.
DuckDB v1.5.0 — which launched on March 9th, literally two days before this benchmark was published — includes optimizations specifically for memory-constrained environments. The timing is not a coincidence. They clearly wanted to demonstrate that their "Big Data on Your Laptop" slogan is not just marketing fluff.
And honestly? After seeing these numbers, I believe them.
What This Actually Means for Your Workflow
I am not going to sit here and tell you to cancel your AWS account. That would be irresponsible, and also I would get angry emails from approximately 400 DevOps engineers. But consider this scenario:
The $14,400 Question
A mid-sized company running analytical queries on a c6a.4xlarge instance 24/7 spends about $4,818 per year. If they run three of those instances (common for redundancy and team access), that is $14,454 per year in compute costs alone. Not counting storage, data transfer, or the engineer babysitting the infrastructure.
For $700 — the price of the MacBook Neo — a data analyst could run those same exploratory queries locally. Faster, on cold runs. Without waiting for a Jupyter notebook to spin up in the cloud. Without VPN issues at 2 AM. Without the monthly AWS bill giving the CFO chest pains.
I showed this math to my friend Rachel, who manages a data team at a mid-sized e-commerce company. Her response was: "We have literally been fighting with Finance about cloud costs for six months. Send me that DuckDB link."
When Cloud Still Wins
Before the cloud evangelists come for me with pitchforks: yes, cloud still makes sense for production dashboards, scheduled ETL pipelines, multi-tenant data platforms, and anything that needs to be always-on and accessible to a team. The 192-core Graviton4 instance finished hot runs 12x faster than the MacBook. For sustained, repeated workloads with caching, cloud infrastructure is still the right call.
But for exploration? For the actual data thinking? Local might genuinely be better.
The Bigger Picture: Why This Benchmark Matters
Look, I have been writing about software for long enough to know that benchmarks are like Rorschach tests — everyone sees what they want to see. But this one feels different.
For the past decade, the tech industry has operated under a shared assumption: big data requires big infrastructure. You need cloud. You need clusters. You need Spark, Hadoop, Kubernetes, a team of six platform engineers, and a prayer circle every Thursday.
What DuckDB just demonstrated — on a $700 laptop, in an Apple Store parking lot — is that this assumption might be outdated. Not wrong, exactly. Just... narrower than we thought. The threshold for "you need cloud for this" keeps moving upward, and tools like DuckDB are doing the pushing.
My friend Tom, who survived the Hadoop era and still has mild PTSD about YARN configurations, put it best: "We spent ten years building complex distributed systems to analyze data that apparently fits on a phone chip. I want those years back."
Same, Tom. Same.
Should You Actually Try This?
If you work with data — any data, really — and you have not tried DuckDB yet, this is your sign. You do not need a MacBook Neo specifically. Any modern laptop with 8+ GB of RAM and a decent SSD will work. The software is free and open source.
Start with a dataset you currently query in the cloud. Export it as Parquet (not CSV — Parquet is compressed and columnar, which DuckDB loves). Run the same queries locally. Time them.
I did this with a 22 GB clickstream dataset last weekend. Cloud query time: 4.2 seconds average. Local DuckDB on my two-year-old MacBook Pro: 3.8 seconds. I genuinely thought something was broken.
Nothing was broken. The data was just... local.
The Bottom Line
A $700 MacBook, running free software, just matched or beat mid-tier cloud servers on analytical workloads that would have required a dedicated cluster five years ago. The cold-run performance advantage comes from having local NVMe storage, which eliminates the network-attached disk penalty that haunts cloud instances on first reads.
This does not mean the cloud is dead. But it does mean that "we need cloud for this" should no longer be the default answer. Sometimes the right infrastructure is already sitting on your desk, waiting for you to install a 30 MB database engine.
Derek, if you are reading this: thank you for the midnight link. And also please start including context when you send URLs. I had three heart attacks before I realized it was not a security breach notification.
