Hatch vs PDM: Python Project Managers Compared
Pick PDM if you want a fast resolver with a built-in lockfile and PEP 582-style local installs; pick Hatch if you want a standardized build backend, environment matrix, and project scripting from one tool.
Hatch (from the PyPA) and PDM are both modern, standards-based Python project managers that replace the older setup.py plus virtualenv plus pip flow. They overlap a lot but emphasize different things: Hatch centers on reproducible environments and its hatchling build backend, while PDM centers on a fast dependency resolver and a committed lockfile (pdm.lock). Both read pyproject.toml.
| Hatch | PDM | |
|---|---|---|
| Config | pyproject.toml ([tool.hatch]) | pyproject.toml ([tool.pdm]) |
| Lockfile | No built-in lock (uses hatch-pip-compile or external) | pdm.lock built in |
| Build backend | hatchling (popular standalone backend) | pdm-backend |
| Environments | Named envs and a test matrix | Single project venv (in-project .venv) |
| Scripts/tasks | hatch run + scripts | pdm run + scripts |
| Standards | PEP 517/518/621 | PEP 517/518/621, PEP 582 history |
Where each genuinely wins
PDM wins when you want a committed cross-platform lockfile and a quick resolver without bolting on extra tools; its pdm.lock and pdm install flow are reproducible out of the box. Hatch wins when you publish packages and want a clean, widely adopted build backend (hatchling) plus a matrix of test environments managed by one CLI. Many projects use hatchling as their build backend even when their day-to-day workflow is pip or uv.
In CI
PDM is convenient in CI because pdm install restores an exact, locked environment from pdm.lock. With Hatch, lock reproducibility usually comes from pinning in pyproject.toml or pairing it with pip-tools/uv; its strength in CI is running the same hatch run test matrix locally and on the runner.
Honest caveats
Neither is universally "better". Hatch deliberately leaves locking somewhat external, which some teams dislike. PDM bundles more (lock, scripts, plugins) but that means more PDM-specific concepts to learn. The fast-moving uv tool overlaps with both, so evaluate it before committing.
Decide with your own numbers, not a feature table
Feature comparisons age badly and rarely decide anything, because both tools in a mature category can do the job. What differs is how each behaves on your repository, and that takes one afternoon to measure.
# time a cold install with each candidate, cache cleared
hyperfine --prepare "rm -rf node_modules" --warmup 1 \
"<tool-a> install" "<tool-b> install"
# and the thing CI actually pays for: a cold run with no local cache
docker run --rm -v "$(pwd):/w" -w /w node:22 sh -c "<tool> install"What actually changes when you switch
- Lockfile format. A switch is a one-way door for anyone still on the old tool until everyone migrates, so plan it as a single coordinated change.
- Resolution strictness. Tools differ on whether an undeclared transitive import works, and the stricter one will surface latent bugs as new failures.
- CI cache configuration. The cache path and key differ per tool; carrying over the old ones silently disables caching.
- Everyone on the team and every runner must move together. Pin the version so they cannot drift.
The verdict
For library authors who want a standard build backend and an env matrix, Hatch fits well. For application teams who want a built-in lockfile and a fast resolver in one tool, PDM is the more complete default.