# How do uv and conda compare?


[uv](https://pydevtools.com/handbook/reference/uv.md) and [conda](https://pydevtools.com/handbook/reference/conda.md) both create isolated environments and install packages, but they draw from different worlds. uv installs Python packages from PyPI. conda installs cross-language binaries from conda channels and ships its own Python. That single difference, where the packages come from, drives every trade-off below.

## Where your packages come from

uv pulls from PyPI: prebuilt wheels and source distributions. For the interpreter itself, uv downloads a prebuilt python-build-standalone binary, so `uv python install 3.13` needs no compiler. Everything uv installs is a Python package.

conda pulls from conda channels: the community-maintained conda-forge channel or Anaconda's default channel. A conda package is not limited to Python. One package can carry a C library, a Fortran runtime, a command-line binary, or an R module. conda ships and manages its own Python interpreter as just another conda package.

That difference decides what each tool can install. If a dependency exists as a wheel on PyPI, uv installs it. If it needs a system library that PyPI cannot ship, conda's channels usually carry it.

## Which is faster?

uv is the faster installer by a wide margin. On an Apple Silicon laptop, `uv add pandas` resolved and installed pandas plus its dependencies from a cold cache in about one second; a warm cache dropped a repeat install to tens of milliseconds. conda's default solver takes tens of seconds to a few minutes on a large environment.

conda has closed part of the gap. Since conda 23.10, the libmamba solver is the default, replacing the slower pure-Python solver. It speeds up resolution but does not match uv, partly because conda resolves heavier cross-language artifacts than uv's Python wheels.

## How reproducible is each?

uv writes a `uv.lock` that pins every transitive dependency with hashes and covers Linux, macOS, and Windows from one file. Committing it makes `uv sync` rebuild the same environment on any machine.

conda's `environment.yml` is a specification, not a lock. It records the packages you asked for, not the exact resolved graph, so two `conda env create` runs weeks apart can produce different versions. Reproducing an exact conda environment across machines needs a separate tool, [conda-lock](https://github.com/conda/conda-lock), which writes a `conda-lock.yml` file.

## How the daily workflow differs

uv is project-local. It creates a `.venv` inside the project, and `uv run` executes commands against it without an activation step. Switching projects means switching directories. Nothing is installed globally, and the environment is disposable because `uv sync` rebuilds it from the lockfile.

conda is global by default. You create a named environment with `conda create -n myenv`, activate it with `conda activate myenv`, and that environment lives in a central directory shared across every project on the machine. The model is familiar to research teams, but it invites environment sprawl and the occasional wrong-environment install.

## Handling CUDA, GDAL, and other compiled dependencies

This is conda's strongest ground. conda resolves a native library, its command-line tools, and the matching Python binding together in one solver pass, which is why the CUDA toolkit, GDAL, HDF5, and MKL-linked builds have lived in the conda world for years.

uv installs compiled packages when they ship self-contained wheels. NumPy, SciPy, and rasterio bundle their native libraries into the wheel, and PyTorch installs through index routing. uv hits a wall when a package has no self-contained wheel and needs a system library whose version must match exactly, like the standalone `osgeo.gdal` bindings. For a package-by-package breakdown, see [uv vs pixi vs conda for scientific Python](https://pydevtools.com/handbook/explanation/uv-vs-pixi-vs-conda-for-scientific-python.md).

## What about licensing?

The conda tool is free, BSD-licensed open source, and conda-forge is free for all use including commercial. What triggers a bill is Anaconda's default channel at `repo.anaconda.com`: any organization with more than 200 employees needs a paid license to use it, and running `conda install` against that channel counts even from a free Miniconda install. Using [Miniforge](https://github.com/conda-forge/miniforge) with conda-forge as the default channel avoids the charge entirely. See [Is conda actually free?](https://pydevtools.com/handbook/explanation/is-conda-actually-free.md) for the full terms.

uv carries no comparable terms. PyPI and uv are free for any use.

## Side-by-side comparison

| Consideration | uv | conda |
|---|---|---|
| Package source | PyPI (wheels, sdists) | conda channels (conda-forge, Anaconda default) |
| Ships the Python interpreter | Yes (python-build-standalone) | Yes (as a conda package) |
| Native / non-Python libraries | Only via self-contained wheels | First-class |
| CUDA, GDAL, MKL | Wheel-dependent | First-class |
| Resolution speed | Fastest | Slower (libmamba is the default solver) |
| Lockfile | Built in, cross-platform (`uv.lock`) | Separate tool (`conda-lock`) |
| Config format | `pyproject.toml` | `environment.yml` |
| Licensing | Free (PyPI) | Tool free; Anaconda default channel commercial above 200 employees |
| Best fit | Pure-Python and PyPI projects | Cross-language, native-heavy scientific stacks |

## Which should you use?

uv is the better default for most Python projects. When your dependencies are on PyPI as wheels, uv installs them faster, produces a `pyproject.toml` any standards-compliant tool can read, and manages Python versions without a second tool. See [How to install Python with uv](https://pydevtools.com/handbook/how-to/how-to-install-python-with-uv.md) to start there.

Reach for the conda ecosystem when you need cross-language binaries or native libraries PyPI cannot ship: the CUDA toolkit resolved against matching packages, the full GDAL stack with its command-line tools, or an MKL-linked numerical build.

If you are adopting conda today for that reason, evaluate [pixi](https://pydevtools.com/handbook/reference/pixi.md) first. pixi installs the same conda-forge packages, adds project-local environments and a single lockfile spanning conda and PyPI dependencies, and carries no [Anaconda](https://pydevtools.com/handbook/reference/anaconda.md) licensing obligation. [When should I choose pixi over uv?](https://pydevtools.com/handbook/explanation/when-should-i-choose-pixi-over-uv.md) covers that decision in depth.

## Learn More

- [How to Install Python (and Which Method to Choose)](https://pydevtools.com/handbook/how-to/how-to-install-python.md)
- [How to Migrate from conda to uv](https://pydevtools.com/handbook/how-to/how-to-migrate-from-conda-to-uv.md)
- [uv reference](https://pydevtools.com/handbook/reference/uv.md)
- [conda reference](https://pydevtools.com/handbook/reference/conda.md)
- [uv vs pixi vs conda for scientific Python](https://pydevtools.com/handbook/explanation/uv-vs-pixi-vs-conda-for-scientific-python.md)
- [Is conda actually free?](https://pydevtools.com/handbook/explanation/is-conda-actually-free.md)
- [Understanding the Conda/Anaconda ecosystem](https://pydevtools.com/handbook/explanation/understanding-the-conda-anaconda-ecosystem.md)
- [What's the difference between pip and uv?](https://pydevtools.com/handbook/explanation/whats-the-difference-between-pip-and-uv.md)
- [How do uv and Poetry compare?](https://pydevtools.com/handbook/explanation/how-do-uv-and-poetry-compare.md)