uv vs Poetry: Speed, Lock-in, and When to Switch

uv wins for new Python applications, CI-heavy workflows, and teams that want one binary replacing pyenv, virtualenv, pipx, and pip. On GitHub Actions, uv resolves a lockfile in 1.4 seconds vs Poetry's 22.3 seconds; that gap compounds across every daily build. Poetry wins for library authors who rely on its mature PyPI publishing workflow and teams with stable existing Poetry codebases.

Key Takeaways

• uv is best for new Python applications, monorepos, CI-heavy pipelines, and developers who want a single binary replacing pip, pyenv, virtualenv, and pipx
• Poetry is best for library authors publishing to PyPI and teams running existing Poetry codebases without a specific pain point
• uv is 4–16× faster than Poetry depending on the operation; CI savings compound per build, per day, per team
• Both tools are free and open-source; the decision turns on toolchain fit, lock-file portability, and migration cost
• uv's pyproject.toml is actually more portable than Poetry's (the counterintuitive finding that changes the lock-in calculation for teams weighing governance risk)

uv vs Poetry: At a Glance

What Is uv?

uv is a Rust-based Python package and project manager built by Astral, first released on February 15, 2024. On March 19, 2026, OpenAI acquired Astral (pending regulatory approval). The tool replaces seven separate Python tools (pip, pip-tools, virtualenv, pyenv, pipx, Poetry, and twine) in a single static binary you can install without Python present on the machine.

uv ranked #1 most admired technology in the Stack Overflow Developer Survey 2025 at 74%. By October 2025, uv had overtaken pip in CI usage for Wagtail and FastAPI. The latest release is 0.11.24 (June 23, 2026), with daily releases reflecting the fastest development pace of any Python tool.

Strengths

• Extreme speed: 10–100× faster than Poetry for dependency resolution; warm-cache lock resolution benchmarks at ~0.33 ms per the official benchmarks
• All-in-one toolchain: replaces pyenv, pip, virtualenv, pipx, and Poetry in a single binary; Docker configs, CI steps, and onboarding instructions collapse from five tools to one command
• PEP 621-compliant pyproject.toml: dependencies live in [project.dependencies] sections any packaging tool can read; switching away from uv later requires no pyproject.toml conversion
• Native workspace support: Cargo-style monorepo workspaces since v0.5.0; shared lockfile, unified resolution across packages, no third-party plugin needed

Weaknesses

• No plugin system: all features ship in the binary; teams relying on Poetry plugins (custom dynamic versioning, private repo hooks) have no direct equivalent
• Two-year-old project: younger than Poetry's seven years; 2,739 open issues reflects rapid scale and an active bug surface
• Publishing workflow thinner: uv publish works; the configuration surface for private registries, multi-repo token auth, and pre-release version workflows is less mature than Poetry's

What Is Poetry?

Poetry is a Python dependency management and packaging tool first released on February 28, 2018 (seven years in production). Created by Sébastien Eustace and maintained by an open-source community with no corporate sponsor. Latest release: 2.4.1 (May 9, 2026).

Poetry handles dependency management, virtual environments, building, and publishing. It does not handle Python version management (you add pyenv) or isolated global tool execution (you add pipx). It has 34,295 GitHub stars and remains widely deployed in codebases from the 2018–2022 period when it was the clearest step up from bare pip.

Strengths

• Mature publishing workflow: poetry publish supports multi-registry auth, poetry version patch for version bumping, plugin hooks, and a battle-tested release flow familiar across Python open-source libraries
• Seven years of stability: known failure modes, consistent semantics since v2.0 (January 2025), and a plugin ecosystem (poetry-dynamic-versioning, poetry-hooks) with no uv equivalent
• Predictable community governance: no corporate backer means no acquisition risk; maintainer track record is stable within the community's release cadence

Weaknesses

• Speed: 22.3 seconds to resolve a lockfile vs uv's 1.4 seconds; the gap compounds across CI matrix runs and Docker layers
• Two-tool requirement: Python version management requires pyenv; one-off CLI tool execution requires pipx; two additional tools before Poetry's own scope begins
• [tool.poetry] format creates real lock-in: dependencies defined under [tool.poetry.dependencies] use sections other tools don't read; switching requires manual pyproject.toml conversion

Speed & Performance: uv vs Poetry

The benchmark data is consistent across independent sources. Danilchenko.dev tested uv 0.7.x against Poetry 2.1.x in May 2026:

Real production numbers match: Ninad Pathak reduced cold build times from 4 minutes to 12 seconds in a production monorepo migration in April 2026. In December 2025, marzeta.pl reported 80% improvement on lock operations after switching.

The minority counter-view deserves a mention. abadugu.com (March 2025) argues: "Poetry's performance is already adequate for the vast majority of Python projects. Unless you're managing massive monorepos with hundreds of dependencies, the difference between a 30 second and 5 second dependency installation is rarely the bottleneck."

For a solo developer who runs poetry install once a week on a small project, 17 seconds isn't a crisis.

Winner: uv. The speed advantage is large and consistent. It matters most at scale.

Toolchain Scope: uv vs Poetry

uv replaces seven separate tools. The five-tool setup common in Python automation workflows collapses to a single binary install:

Hynek Schlawack (production Python infrastructure at Variomedia, PyCon speaker) demonstrated a fully configured production Python project using zero uv-specific settings:

"At this point so far we have used zero uv specific settings or features. We've only used standard Python packaging settings. Everything so far should work whether you use uv or not."

Hynek Schlawack, uv project layout talk (YouTube, 2025)

Poetry covers dependency management, building, and publishing. Anything outside that scope (Python version management, isolated CLI tool execution) requires separate tooling. For teams reducing their stack before containerizing or scaling CI, that's a non-trivial operational difference.

Winner: uv. Replaces seven tools; Poetry handles one job well.

Lock Files & Standards Compliance: uv vs Poetry

The conventional narrative frames uv (VC-backed, OpenAI-acquired, two years old) as the riskier bet on lock-in. The actual data reverses it.

uv's uv.lock sits on a PEP 621-compliant pyproject.toml. Your dependencies live under [project.dependencies]: a section any packaging tool (hatch, flit, pdm, setuptools) can read without modification. If uv ever changes in ways you dislike, your pyproject.toml requires zero conversion to switch.

Poetry's poetry.lock sits on [tool.poetry.dependencies] sections. Poetry added PEP 621 support in v2.0 (January 2025), but many existing projects still use the pre-standard [tool.poetry] format. Other tools don't read those sections.

Switching from Poetry requires a manual pyproject.toml conversion: real migration work.

The lock-in analysis cuts against the intuitive framing. Poetry's dependency source configuration lives in [tool.poetry] sections that other packaging tools don't read, while uv's PEP 621-compliant pyproject.toml is readable by any standard-compliant tool. After the OpenAI acquisition, this matters: the exit cost from uv is lower than the exit cost from Poetry.

The uv.lock file is also universal, resolving identically across macOS arm64, Linux x86_64, and other platforms. poetry.lock is project-specific.

Winner: uv. Less proprietary format despite the corporate backing. If Astral's direction changes post-acquisition, your pyproject.toml needs no conversion to switch tools.

Python Version Management: uv vs Poetry

uv handles Python version management natively:

uv python install 3.13
uv python pin 3.12

A .python-version file pins the interpreter per project. uv run picks it up automatically. Downloads use prebuilt binaries and take seconds. You can maintain Python 3.10, 3.11, 3.12, and 3.13 side-by-side and switch per-project without any additional tool.

Poetry has no Python version management. The standard setup:

pyenv install 3.12.6        # compiles from source, minutes
pyenv local 3.12.6
poetry install

Every new Python version requires manual pyenv steps. For developers setting up Python for beginners environments, the two-tool bootstrapping ceremony is a common stumbling block: which tool owns the Python interpreter, and when?

Winner: uv. Built-in version management removes pyenv from the stack entirely.

CI/CD & Docker: uv vs Poetry

uv's strongest case is CI arithmetic, not local install speed.

A team running 30 CI builds per day saves approximately 18 minutes of build time daily after switching from Poetry (~45s per run) to uv (~8s per run). Across a month, that's ~9 hours of recovered compute per team. Sebastián Ramírez, creator of FastAPI (4M+ daily downloads), migrated all his projects to uv for one reason: compounding CI savings.

FastAPI, Typer, SQLModel, and Asyncer all run on uv in CI as of October 2024.

Docker builds compound the same way. Layers that took 60–90 seconds with Poetry drop to seconds with uv.

The official uv Docker image supports distroless multi-stage builds with --frozen and --no-install-workspace flags for clean production containers. Poetry's Docker path is more verbose and relies on pip at some steps.

On r/Python, a 447-upvote migration thread documented an unexpected benefit: uv's stricter project isolation surfaced global pip installs and untracked dependencies that had been invisible under looser tooling. The migration became a codebase health audit, not just a speed upgrade.

Winner: uv. CI savings compound: ~18 min/day recovered for a 30-build team. Docker layers that took 60–90 seconds with Poetry drop to seconds.

Publishing to PyPI: uv vs Poetry

This is the one category where Poetry holds a clear advantage.

Poetry's publishing workflow is the most mature in the Python ecosystem: multi-registry auth tokens, poetry version patch for version bumping, and plugin hooks via poetry-dynamic-versioning. The release flow has been standard in open-source Python libraries since 2018, and private repository configuration, trusted publishing via OIDC, and pre-release workflows all have battle-tested documentation.

uv has uv publish + uv build. Trusted publishing via GitHub Actions OIDC is the recommended path and works cleanly. The configuration surface for private registries, multi-repo token auth, and pre-release version management is thinner.

Andrew Odendaal's analysis captures the 2026 practitioner consensus: "New projects get uv. Existing Poetry projects stay unless there's a specific pain point." For library authors who poetry publish weekly, the friction of leaving is real.

Winner: Poetry. Its publishing configuration surface is the deepest in the Python toolchain.

Pricing: uv vs Poetry

Both tools are free and open-source.

uv is Apache 2.0. Development is funded by Astral (acquired by OpenAI March 2026). No paid tiers, no SaaS subscription, no usage limits.

Poetry is MIT. Development is community-funded with no corporate sponsor. No paid tiers.

Cost is not a differentiator. The decision rests on toolchain fit, lock-file portability, and migration cost.

Governance and the OpenAI Acquisition

OpenAI announced the acquisition of Astral on March 19, 2026 (pending regulatory approval), with Astral's team joining the Codex group.

The 363-upvote r/Python thread on the acquisition settled the governance question quickly. The Apache 2.0 license makes community forks viable; one fork exists already; and uv's PEP 621-compliant pyproject.toml makes migrating out straightforward. Simon Willison's acquisition analysis reached the same conclusion.

The "governance risk" framing now paradoxically favors uv. uv has the strongest funding and fastest release cadence; the Apache license and portable format keep exit cost low. Poetry has the most predictable community governance; slower release cadence and no acquisition risk. Neither is a clear danger; developers evaluating new projects should weigh governance risk alongside the lock-in data from the Lock Files section above.

When to Use uv vs Poetry

The ML/conda-forge exception matters on Pynions. uv handles PyPI-only dependencies cleanly and quickly. If your data or AI project needs packages from conda-forge channels (PyTorch nightly builds, certain CUDA libraries, HPC tools), uv cannot install conda-channel packages. Use pixi for mixed conda-forge + PyPI environments, or pair uv with conda for the non-PyPI layer.

Migrating from Poetry to uv

Migration is mostly mechanical. The migrate-to-uv tool converts pyproject.toml automatically. The core steps:

• Run migrate-to-uv to convert [tool.poetry] sections to [project] (PEP 621 format)
• Remove remaining [tool.poetry] blocks
• Run uv sync to generate uv.lock from scratch
• Replace poetry run with uv run in scripts and CI configurations
• Update CI to use the astral-sh/setup-uv GitHub Actions action

After four production migrations, George Shuklin described the process as "absolutely zero issues". Main friction appears in plugin-heavy setups: poetry-dynamic-versioning, custom build hooks, and [tool.poetry.group.X] dependency group syntax need manual handling.

What stays intact: core pyproject.toml structure, dependency version specifiers, test and linting configuration. What doesn't carry over: poetry.lock is not compatible with uv.lock; expect a fresh resolution on first uv sync. You cannot convert poetry.lock directly.