uv vs Poetry vs pip vs PDM: Python Package Managers in 2026
I timed the same 59-package install four ways: pip takes 15 seconds warm, uv takes half a second. Plus what the OpenAI acquisition actually changes, and the lockfile standard nobody mentions.
The download counts have stopped being close. On PyPI, uv is pulling about 203 million downloads a month against Poetry’s 80 million as of 21 August 2026. Two years ago uv did not exist. People do not switch package managers for entertainment, so a swing that size is reporting something.
What it is reporting is mostly speed, so let me put a real measurement up before the opinions.
What I measured
I timed the same install four ways on an Apple silicon Mac against Python 3.14: 20 top-level requirements for an ordinary web service, Django and DRF and Celery and SQLAlchemy and boto3 and pandas and the usual test tooling, which resolve to 59 packages. Each run went into a fresh virtualenv. uv was 0.11.6, pip was 26.0.
The detail I did not expect is the middle two bars. pip with a fully populated cache came in at 15.2 seconds against 17.4 with --no-cache-dir, a 13% improvement, because most of pip’s time is not spent downloading. uv’s cache, by contrast, takes it from 3 seconds to half a second.
That is the part that matters for CI, where the cache is either warm or cheap to make warm. It is also why the wins get quoted so inconsistently: cold-versus-cold is about 6x here, warm-versus-warm is about 30x, and both are true.
For a five-dependency script, none of this is noticeable. Speed is a fleet problem.
uv is still not 1.0
It is on 0.12.5 as of August 2026. The pre-1.0 number has never meant “toy,” and plenty of teams run it in production CI, but it does mean the CLI and the config surface can move between releases. Pin the version in CI and you will not be surprised. Anyone telling you uv shipped 1.0 is telling you about a release that has not happened.
For reference on the rest of the field: Poetry is on 2.4.1, PDM on 2.28.2, pip on 26.2.1.
Lockfiles now have a standard, and it is not uv’s
This is the part missing from most comparisons, including the one this post replaces.
PEP 751 is Final. It was accepted on 31 March 2025 and defines pylock.toml, a standard lockfile format that records direct and transitive dependencies with versions, sources, hashes, and environment markers, and is designed so that installing needs no resolution step. Four years of argument, resolved.
Support is uneven in an interesting way. pip, PDM, and uv can all produce it. On my machine uv export --format pylock.toml and uv pip compile --format pylock.toml both work today. Poetry tracks it in an open discussion and has not shipped it.
But nobody has adopted it as their native format. uv keeps uv.lock for projects and treats pylock.toml as an export target, because the standard does not yet capture everything a per-tool lockfile does, notably uv’s single cross-platform resolution. So the practical state is that the standard is a lingua franca for handoff and SBOM-adjacent work, not the file your project lives on.
Which is still worth something. If your worry about adopting uv was lockfile lock-in, that worry now has an exit.
Where the four actually differ
Poetry, PDM, and uv all give you cross-platform lockfiles with hashes. pip does it through pip-compile, which plenty of shops still use and are right to. uv’s lockfile is universal, resolving once for all platforms rather than for the machine that generated it. Poetry’s format has matured to the point that the difference is resolution speed rather than correctness.
Monorepos are a real differentiator. uv has first-class workspaces, with uv sync --all-packages and uv run --package api. Poetry closed much of that gap through 2026, so older Poetry guides will mislead you here. PDM has workspace support too.
Python version management is uv’s quiet advantage and the one I would weight highest for a new machine. uv python install 3.12 fetches and manages the interpreter, which retires pyenv from the setup. Poetry and PDM both expect you to bring your own Python.
And PDM’s headline feature died. Its original pitch was PEP 582 and a project-local __pypackages__ directory instead of a virtualenv. PEP 582 was rejected by the steering council, so it never became a standard, and PDM deprecated the feature. PDM remains a good, standards-compliant manager. It just no longer has a thing uv does not also do faster.
The OpenAI question
OpenAI announced on 19 March 2026 that it is acquiring Astral, the company behind uv, Ruff, and ty, with Charlie Marsh and the team joining the Codex group. As of late August the deal is still subject to regulatory approval, so it is announced rather than closed.
The reassurances are real and specific. Both companies committed publicly to keeping the open source tools open. uv and Ruff carry permissive licenses, which makes them forkable in a way that a proprietary tool never is, and several people made exactly that point in the days after the announcement, including Simon Willison.
The concerns are also real. A piece of critical Python infrastructure now sits inside a company with direct competitors in AI. And pyx, Astral’s commercial package registry, went unmentioned in both announcement posts, which is the kind of silence that is worth noticing rather than interpreting.
My read: for the open source tool in your CI, this barely moves. The license makes it forkable and the userbase makes abandonment self-harming. For the commercial products, the uncertainty is genuine and I would wait for a post-close roadmap before signing anything.
What to actually use
New project: uv. It is faster, it handles interpreters and virtualenvs, the workspace support is solid, and the momentum means the answers you find will increasingly assume it.
Existing Poetry project that works: leave it. Poetry did not get worse because uv got faster. If your CI install time is not a pain point, replacing a working setup to save seconds is busywork. If it is a pain point, the payoff is concrete and measurable in the numbers above.
On PDM: fine to stay, hard to recommend starting.
The migration you do not have to do
uv ships a pip-compatible interface. uv pip install, uv pip compile, and uv pip sync operate on your existing requirements.txt with no pyproject.toml rewrite and no new lockfile format.
So the lowest-risk way to adopt uv is to change one line in CI: pip install -r requirements.txt becomes uv pip install -r requirements.txt. If it breaks, you revert one line. On the numbers above that swap alone is most of the win, and CI minutes are billed by the minute on every provider I have looked at, which I went through in detail for GitHub Actions pricing.
Full project adoption is a separate decision you can make later, with no clock running.
One thing worth sitting with
uv did not win by inventing anything. Lockfiles, project management, interpreter pinning: Poetry and PDM shipped all of it first, and PEP 751 standardized the idea before uv had a chance to own it. uv won by doing the same things fast enough that the friction stopped being a thing you plan around.
That is worth remembering next time you evaluate a tool on its feature matrix. Half a second against fifteen is not a feature. It changes how often you are willing to run the thing at all.