How uv Made Python Packaging 100 Times Faster

Astrals uv installs Python packages up to 100 times faster than pip, and according to the video "How Rust made Python packaging 100x faster" from the Let's Get Rusty channel, the tool is now downloaded almost 200 million times a month with close to 90,000 stars on GitHub. Those adoption numbers matter because they tell you this is no longer a curiosity for Rust enthusiasts. Python developers, a population famously allergic to changing their toolchain, have switched.

The interesting question is why. The video, written from an obvious pro-Rust vantage point, attributes the speed to the language. That is partly true, and partly a sales pitch. Walk through the three engineering decisions the video lays out and a more complicated picture emerges: the speed comes from architecture first, language second.

Decision One: Download Only What You Need

A Python package ships as a wheel, which is a zip file. PyTorch's wheel runs about 500 megabytes. Buried inside it is a metadata file of roughly 40 kilobytes that lists the package's dependencies. A package manager needs that metadata before it can install anything, and it may need to check several versions to find one compatible with your project.

On major indexes like PyPI, metadata is published separately. On custom indexes, including a company's private index or a special CUDA build of PyTorch, it may only exist nested inside the wheel. pip, facing that situation, downloads the entire 500 megabytes to read 40 kilobytes, possibly several times, discarding each wheel after reading it.

uv instead uses an HTTP range request: a normal web request with one extra header that says, in the video's paraphrase, "Send me only these bytes." A wheel's zip central directory maps exactly where every internal file begins and ends, so uv can jump straight to the metadata. As the video puts it, "This downloads 40 kilobytes across the network instead of the 500 megabytes." The same trick your browser uses when you skip ahead in a video.

Why didn't pip just add this? It partly has, with experimental flags, but pip must work against 15 years of older indexes, and per the video the feedback on those flags is that "it is not reliable and often is not faster." uv made range requests the default on every index because it never inherited those constraints.

Notice what this optimization actually required: knowledge of the zip format and a willingness to change default behavior. Rust appears nowhere in the description.

Decision Two: Never Copy the Same File Twice

Install NumPy into three virtual environments with pip and you get three complete copies of NumPy on your disk. uv keeps one copy in a global cache and links every project to it. The video walks through uv's link mode, a Rust enum with four variants:

• Clone: on macOS and Linux with a copy-on-write filesystem, a second file is created that points at the same disk blocks. No bytes are duplicated; a second NumPy install adds a directory entry, not another 18 MB.
• Hard link: the fallback, used on Windows. One file on disk with two names.
• Copy: the full byte-for-byte duplication pip performs.
• Symlink: a small file storing a path to the original, which breaks if the original is deleted. uv never picks this on its own.

Here's the detail that undermines the pure-language story: pip can create hard links too. The video concedes this directly, saying the reason pip doesn't is "because of an architectural decision. Pip copies bytes into one environment at a time. In contrast, uv built a shared cache from the ground up with the expectation to link from that cache." Architecture, again. A shared cache plus linking was available to a Python implementation; nobody built it.

Decision Three: Concurrency Without the Baggage

The third decision is the one where Rust earns its keep. Older tools download one package, wait, unzip it, then start the next, leaving every CPU core idle except one. uv runs all downloads simultaneously, starts unzipping each package the moment its own bytes arrive, and sorts packages by size, biggest first, so the largest download gets the entire install to finish in.

Could a Python package manager do the same? The video argues no, and the argument is sound. Python's global interpreter lock means only one thread executes Python code at a time; ten threads take turns. Processes do run in parallel, but nothing is shared between them, and for a package manager "the time spent copying data between processes can easily cost more than the time saved by running them at once." Rust threads share memory directly, with the compiler proving the sharing is safe before the program runs.

Python is fixing this. Free-threaded builds arrived in Python 3.13 and are officially supported in 3.14, though they are not yet the default. The video's framing, that uv's developers used Rust's concurrency model "rather than waiting for a language to catch up," is fair. A generation of tools in other languages, from ripgrep to esbuild, made the same choice.

What the Video Doesn't Settle

There are tensions here the source, being essentially a Rust advocacy piece with a mentorship program attached, doesn't explore.

First, the 100x figure. Benchmarks showing 100x speedups typically measure cold installs of large dependency trees against specific competitors. Aron Hack's writeup at aronhack.com cites "10-100x faster performance compared to pipenv," a tool few speed-focused developers use as a baseline anyway. Against pip on a warm cache with a small project, the gap narrows considerably. The honest range is wide, and where your workload sits in it depends on your index, your platform, and your filesystem.

Second, uv is more than a fast pip. Calmops notes it comes from the same team behind the Ruff linter and consolidates the functions of multiple utilities into one tool; Hack's piece adds built-in security vulnerability scanning across the dependency tree. Consolidation has its own risks: a single company, Astral, now sits underneath a large and growing share of the Python ecosystem's daily workflow. pip is a community project with PSF governance. uv is venture-funded infrastructure. That tradeoff, speed and polish versus independent stewardship, doesn't appear in the video, and it's the one I'd weigh most carefully before standardizing a team on uv.

Third, the Xebia analysis at xebia.com points to a fourth optimization the video skips: uv parses pyproject.toml files with Rust's native parsing libraries, "eliminating the Python startup" that costs traditional tools hundreds of milliseconds before they even read a file. Every millisecond counts when your baseline install takes 600 milliseconds, as the video claims uv does.

The Lesson Nobody in the Video Says Out Loud

The three decisions, download only what you need, never copy a file twice, never idle, are all ideas that predate uv by decades. HTTP range requests are ancient. Copy-on-write filesystems shipped with Btrfs and ZFS years ago. Async I/O exists in every major language. What uv's team did was look at a mature, beloved, slow tool and ask which of its constraints were physical laws and which were accumulated compromises. Most were the second thing.

Rust made the third decision cheap to implement and safe to ship. But the gap pip couldn't close was architectural, and closing it required starting over. Python's own ecosystem is now having that argument with itself, one 500-megabyte wheel at a time.

Marcus Chen-Ramirez covers AI, software development, and the economics of tooling for Buzzrag.