A database benchmark measures a whole system
Read DuckDB hardware results with their compiler, memory, storage and run conditions. A useful stack comparison is narrower than a CPU architecture verdict.
By 
Paul. Architecture and infrastructure
A database benchmark can help choose a deployment without identifying the intrinsic merit of a processor architecture. The distinction depends on the question. A buyer may care about an available machine running an available software stack. An architecture claim needs evidence that separates that architecture from the other differences. Treating those questions as interchangeable makes a concrete experiment carry more weight than its setup supports.
Two DuckDB articles illustrate the difference: DuckDB on LoongArch, dated 6 January 2026, and TPC-H on a Raspberry Pi, dated 17 January 2025. They report experiments by DuckDB's authors. This November 2026 discussion runs no benchmark, computes no new speedup and makes no procurement guarantee. The useful lesson concerns how to carry experimental context into a decision.
Keep the tested stack attached to the result
Hannes Mühleisen reports a MOREFINE M700S with a Loongson 3A6000, 16 GB RAM and a 256 GB SSD. The stack used Loongnix, Linux 4.19 and GCC 8.3, with patched DuckDB 1.4.3 and a workaround for CMake 3.13.4. The comparison used an M3 Max MacBook Pro, 14 GB DuckDB memory limits on both systems, and all 22 TPC-H queries at SF100 and SF300. Timings came from the second, hot run. Those are conditions of the reported experiment.
The author finds the MacBook faster in that comparison and discusses toolchain and I/O as possible contributors. That does not isolate a causal effect for the instruction set. A shared memory limit makes one important condition comparable; it does not equalize the operating system, storage, compiler maturity or all other hardware. The result remains useful at its actual scope.
A procurement discussion should retain those distinctions. If the intended machine ships with that software environment, its limitations are part of the product the buyer would operate. If the question concerns a future port with a different compiler, the experiment offers a baseline and questions to investigate. It cannot supply measurements for software that was not tested.
The Pi experiment changes the storage question
Gábor Szárnyas reports a 16 GB Raspberry Pi 5, a 128 GB microSD card and a 1 TB Samsung 980 NVMe SSD, assembled in an Argon ONE V3 case with heat sinks. Raspberry Pi OS was dated 2024-11-19; the January timings used DuckDB 1.2-dev, commit 0024e5d4be. The experiment compared cold runs of the 22 TPC-H queries at SF100 and SF300 across the two storage options. The maintained article separately updates completion support for 1.2.2 and newer. That update does not redate the original measurements.
Here, storage is central to interpreting the result. Work that spills beyond memory depends on the path to temporary data as well as the CPU. Reading a board name while omitting the SSD would describe a different purchasing proposition. A minimal board and a complete cooled system with storage are different artifacts even when they share the same processor.
The author also says these are unofficial TPC-H results covering read queries. A recognized workload name helps explain what ran; it does not turn the experiment into an official audited result or a general mixed-workload test. Keep that qualification when comparing it with other published numbers.
Cold and hot runs answer different operating questions
The LoongArch article uses second-run timings; the Pi article describes cold runs. Combining their tables into an architecture ranking would discard that difference alongside the database-version change. A fairer use is to identify the operating conditions relevant to the intended application and look for evidence matching those conditions.
A service repeatedly querying familiar data may care about warm behavior. A scheduled job that starts fresh may care about the first complete run. Neither condition is universally more honest. The mistake is choosing whichever number looks attractive while describing a different workload. A proposed comparison should name the lifecycle being purchased before selecting its measurement boundary.
Thermal context deserves the same care. A case, heat sinks and a reported fan describe parts of the physical setup. They do not establish equal temperatures, sustained power limits or the absence of throttling across machines. The articles do not provide a controlled thermal comparison that would justify attributing differences to heat alone. Record that uncertainty instead of inventing an explanation.
Whole-system evidence can still be enough
The strongest counterargument is that buyers rarely purchase an instruction set in isolation. They purchase a complete system and need to know whether it can finish useful work. An imperfect comparison of available stacks can answer that immediate question better than waiting for a laboratory study that removes every practical difference.
That argument is persuasive when the claim stays close to the deployment. Completion of a relevant workload under an acceptable resource budget can matter even without a causal breakdown. It becomes weaker when an old desktop experiment is used to forecast a future platform, rank every processor in a family or promise today's price/performance.
For a proposed purchasing evaluation, define acceptable completion time, data size, concurrency and support expectations. Include storage and cooling in the configuration being evaluated. Record the compiler and database version alongside the queries. These are suggested acceptance conditions, not an evaluation conducted by AL+ and not a claim that either article establishes those conditions for a customer.
Match the next measurement to the unresolved question
If the concern is spilling, investigate the storage path under the expected memory allowance. If it is short-lived query execution, preserve startup and cold-state costs. If compiler maturity is the question, compare the relevant builds deliberately while keeping the workload and hardware clear. Each investigation can narrow uncertainty without pretending to explain every observed difference.
For custom software development, ask which complete configuration can meet the application's needs and what remains unmeasured. Use the DuckDB experiments as attributed evidence about their tested systems. Keep architecture conclusions, future performance forecasts and procurement commitments separate until evidence actually supports them.