Nix offers an unparalleled collection of readily packaged C/C++ libraries, with the added benefits of cross-compilation support and a declarative configuration language. That's why we chose it to manage third-party dependencies for our Bazel-built monorepo. This not-too-common use of Nix as a polyglot build system for external libraries and tools led us to approach Nix in a different way, both in how we think about it and how we used it. Our usage scenarios seemed rarely exercised an we found several opportunities for optimization in Nix code itself. At the core of the problem, we had 300+ packages that we needed to evaluate and build on demand. These evaluation times quickly added up, and we had to rethink the design to get some optimizations. This task set is embarrassingly parallel as each package evaluation is independent. But we realized along the way that full parallelism wasn’t the best we could do. We will explain how we leveraged nix evaluation caches (plural!), flakes, manually crafted store paths and parallel execution to reduce evaluation time from 5 minutes to 5 seconds, and bring other less quantifiable improvements. The work led to a few interesting scripts and two main PRs to nix itself (see below), one of which is already merged and released while the second is subject to discussion because of its impact on other cached operations. We will use that discussion to illustrate the tradeoffs of caching parallel evaluation. about this event: https://talks.nixcon.org/nixcon-2025/talk/FZNRLC/ Video:import-56394-eng-Embarrassingly_parallel_evaluations_hd.mp4