uv vs pip vs Poetry: Python Package Managers in 2026

Three tools, three jobs. If you are starting a Python project in 2026 and trying to pick between uv, pip, and Poetry, the honest answer is that you will probably touch all three at some point — but only one of them deserves to be your default. Speed used to be the whole argument. It isn't anymore.

Standards compliance and how much these tools consolidate into a single binary now matter just as much. And the speed numbers everyone quotes turn out to hide something, which I measured below.

Here is where each one stands.

pip — the baseline everyone shares

pip ships with CPython through ensurepip, which means it is the one tool you can assume exists almost everywhere. (Some Linux distributions split it out of their system Python package.) That alone keeps it relevant no matter how fast the alternatives get. And pip has not stood still.

Two recent additions are worth knowing. First, lockfiles: pip lock can write a standardized pylock.toml (the format defined by PEP 751), and since 26.1 pip can install from one with pip install -r pylock.toml. Both are still marked experimental. Second, dependency cooldowns: refusing any package version published within the last N days.

The cooldown flag is --uploaded-prior-to. It arrived in pip 26.0 accepting only an absolute timestamp; 26.1 added relative durations, which is what makes a rolling cooldown possible. The accepted formats are narrower than "ISO 8601 duration" suggests. On pip 26.2.1, P7D and a full timestamp such as 2026-09-01T00:00:00Z work, while P1W and PT12H are rejected. Use days.

The case for a cooldown comes from William Woodruff's analysis of ten supply-chain attacks: eight had exposure windows under a week, so a 7-day cooldown would have prevented most of them. pip 26.1 also dropped Python 3.9, so check your floors before upgrading.

Reach for pip alone when you want the lowest common denominator: a minimal container, a CI base image, a one-off pip install, or teaching someone their first virtualenv.

Poetry — built for people who publish

Poetry's strength has always been the declarative pyproject.toml workflow: dependency groups, a clean resolver, and a poetry publish path to PyPI that library maintainers genuinely like. The 2.x line kept sharpening that niche.

Official Python 3.14 support arrived in Poetry 2.2.0. Version 2.3.0 added pylock.toml export (through poetry-plugin-export) and flipped the installer.re-resolve default to false. Poetry 2.4.0 added its own cooldown setting, solver.min-release-age. The current release, 2.5.1 (September 20, 2026), adds official Python 3.15 support. Poetry still can't replace poetry.lock with pylock.toml, but it can emit one for tooling that expects the standard format.

The trade-off: Poetry is one more thing to install and learn, and — as the measurements below show — it is slower than you might expect on a cold cache. If you ship libraries and value a mature, opinionated publishing flow, that cost is easy to justify. If you are building an application, it is harder.

uv — the consolidator

uv is a single Rust binary from Astral that takes over the jobs of pip, pip-tools, pipx, pyenv, virtualenv, and twine. It manages Python interpreters, virtual environments, tools, and workspaces. Its uv pip interface covers the common pip workflows, though Astral's own docs are clear it is not an exact clone, and list the differences. The native uv.lock is fast and reproducible, and uv can also export and install pylock.toml. For cooldowns, --exclude-newer plays the same role as pip's flag.

uv 0.12.0 (July 28, 2026) was a release with breaking changes. The one you will notice first: uv init now creates a packaged project using uv's own build backend and a src/ layout by default.

Licensing is permissive: dual MIT/Apache-2.0 and free to use. That matters because OpenAI announced an agreement to acquire Astral on March 19, 2026. Whatever happens to the company, the license means anyone can freeze the source at any commit and keep going.

The speed gap, measured

Most speed tables for these tools, including the one this article used to carry, are assembled from other people's benchmarks. So I ran my own, with conditions I could control.

The setup: the same 37 pinned packages for each tool — Django, Celery, pandas, scikit-learn, requests, pytest and their dependencies, about 232MB of wheels — installed into a fresh virtual environment with Python 3.14 on an Apple M5. "Cold" means an empty cache, so everything downloads. "Warm" means a populated cache. Each tool got its own isolated cache directory, the order was shuffled between rounds, and each number is the median of three runs.

The default-versus-default comparison looks like the marketing: uv is 8× faster than pip cold and about 50× faster warm. But the defaults do different amounts of work. pip compiles every installed module to bytecode (.pyc files) as it installs; uv and Poetry skip that step unless you ask. Skipped work does not disappear — Python compiles each module the first time it is imported instead.

Compare like with like, bytecode on both sides, and uv is 3.8× faster than pip on a cold cache and 5.2× faster warm. That is still a large, real advantage. It is not 100×, and the gap between the two numbers is mostly one flag.

Poetry is the surprise in the other direction. Warm, it is quick. Cold, it was the slowest of the three, and with bytecode compilation turned on it took twice as long as pip.

Resolving a lockfile without installing tells the same story in miniature. All three tools resolved the unpinned spec to exactly the same 37 versions.

One caveat: poetry lock writes a lock for every platform, which is why it added one extra, Windows-only package (colorama), while pip lock and uv pip compile resolved for this Mac only. Poetry is doing slightly more work there.

Two practical notes for your own benchmarks. Cold numbers depend heavily on your network, so the cold column is really "your connection plus the tool". And if you compare uv to pip, pass --compile-bytecode to uv, or you are comparing different jobs.

Standards are converging

All three now revolve around pyproject.toml, and all three can speak the standardized pylock.toml lockfile from PEP 751, which is now final. pip writes and reads it (both experimental), Poetry exports it, and uv exports and installs it alongside its own uv.lock. Lockfile portability between tools is finally becoming real. Keep your lockfile in version control no matter which tool you pick.

What to actually use

Migrating from pip is low-risk: uv pip install handles the common pip install workflows and uv pip compile replaces pip-tools.

Migrating from Poetry has a trap. uv reads the standard [project] table in pyproject.toml, not Poetry's own [tool.poetry.dependencies] section. If your project still uses the classic Poetry layout, uv lock does not fail. I ran it against a 37-dependency Poetry-style project: it exited successfully, printed "Resolved in 2ms", and wrote a lockfile containing zero packages. The only warning was about a missing requires-python. Move your dependencies into a [project] table first — Poetry 2.x already supports that layout — then run uv lock, and check that the lockfile actually lists your packages.

Default to uv, never stop understanding pip, and reach for Poetry when you publish libraries. Re-check the version numbers with --version and the PyPI pages before you commit — this corner of the ecosystem moves fast enough that any article, including this one, ages in months.

Quick start: a virtual environment with uv

If all you need is the job python -m venv plus pip used to do — an isolated environment with a few packages in it — uv's pip-compatible commands cover it without a project file.

Install uv with the standalone installer, the first option in Astral's installation docs (brew install uv and pipx install uv also work):

# macOS / Linux
curl -LsSf https://astral.sh/uv/install.sh | sh

# Windows (PowerShell)
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

Then create the environment and fill it:

uv venv                            # creates .venv in the current directory
uv pip install requests            # installs into .venv, no activation needed
uv pip install -r requirements.txt
uv pip list
uv run python -c "import requests; print(requests.__version__)"

To pin an interpreter, create the environment with uv venv --python 3.11 instead. If that version isn't on the machine, uv downloads it.

Three things differ from venv habits:

• Activation is optional. When the environment uses the default .venv name, uv finds and uses it automatically on later commands (uv docs). Activate it (source .venv/bin/activate, or .venv\Scripts\activate on Windows) only when you want python and console scripts on your shell's PATH directly.
• The environment starts empty — not even pip. uv venv installs no seed packages unless you pass --seed, so python -m pip fails inside it. Use uv pip instead, and if an import fails and you're not sure which environment you're in, the ModuleNotFoundError guide walks through checking.
• How you update uv depends on how you installed it. uv self update works only for the standalone installer, and it re-runs that installer, which can modify your shell profile (set UV_NO_MODIFY_PATH=1 to prevent that). If you installed through pip, pipx or Homebrew, upgrade through that tool.

Once you're managing a project rather than a scratch environment, move to the project commands — uv init, uv add <package>, uv run <script>. Dependencies then live in pyproject.toml, uv.lock pins them, and uv creates and syncs .venv for you. Remember that since 0.12.0, uv init creates a packaged project with a src/ layout by default.

References

• Release histories: pip, Poetry, uv; uv 0.12.0 release notes
• pip changelog and What's new in pip 26.1 (Richard Si)
• We should all be using dependency cooldowns (William Woodruff)
• Announcing Poetry 2.3.0 and Poetry releases
• uv's pip compatibility notes and PEP 751
• uv docs: Installing uv · Using Python environments
• Astral joining OpenAI (Astral blog)
• Measurements: Apple M5 MacBook Pro, macOS 26.6.2, Python 3.14.6, 2026-09-28