If you’ve been working with Python (or really any language) for a while, chances are you’ve used pre-commit. It’s been the de facto standard for managing git hooks for years. You define your hooks in a .pre-commit-config.yaml, run pre-commit install, and you’re good to go. It handles the installation and execution of hooks written in any language, without requiring root access.

But recently, as I found out at FOSDEM, a new tool has been making the rounds: prek. It’s like a version of pre-commit, built in Rust. And if you’ve been following the Python ecosystem, you’ll notice a trend here. First we got Ruff as a replacement for Flake8, Black, and isort. Then uv came along to replace pip venv (and maybe even Poetry). Now prek is here to speed things up as well.

The Rust rewrite of pre-commit is gaining traction fast. For a couple of my projects I decided to give prek a shot and see how it compares to good old pre-commit. Let me walk you through the differences.

A quick recap

pre-commit

pre-commit has been around since 2014 and has a massive ecosystem. It’s a multi-language package manager for git hooks. You specify the hooks you want, and pre-commit manages everything: downloading the tools, setting up isolated virtual environments, and running the hooks on every commit.

A typical configuration looks like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.6.0
    hooks:
      - id: check-yaml
      - id: end-of-file-fixer
      - id: trailing-whitespace
  - repo: https://github.com/astral-sh/ruff-pre-commit
    rev: v0.8.0
    hooks:
      - id: ruff
      - id: ruff-format

Getting started is straightforward:

1
2

pip install pre-commit
pre-commit install --install-hooks

That’s it. Now every time you commit, your hooks will run.

prek

prek is a drop-in replacement for pre-commit, built in Rust by j178. It’s designed to be faster, dependency-free, and fully compatible with your existing .pre-commit-config.yaml. That last part is key: you don’t have to change your configuration at all.

Installation is just as simple:

1
2
3
4
5
6
7

# Using uv (recommended)
uv tool install prek
# or
uv add --dev prek

# Or via pip
pip install prek

The migration? Two commands:

1
2

pre-commit uninstall
prek install

That’s it. No configuration changes, no compatibility issues. Your existing .pre-commit-config.yaml works as-is.

So why would you switch?

Speed

Let’s be real, this is the main reason. pre-commit is written in Python and creates isolated virtual environments for each hook. This architecture is robust, but it introduces overhead. Especially the initial setup can take a while.

prek is significantly faster. According to the official benchmarks, installing hooks for Apache Airflow (which has a large and complex pre-commit configuration) took about 18 seconds with prek versus 187 seconds with pre-commit. That’s roughly 10x faster. For runtime, the numbers vary but prek is consistently 2-5x faster, depending on the hooks and whether the fast path is enabled.

On the CPython codebase, running check-toml across all files:

That’s about 4.5x faster. And these numbers get more dramatic with cold caches and larger hook configurations.

Disk space

prek redesigned how hook environments and toolchains are managed. Instead of creating a separate virtual environment for each hook, it shares toolchains between hooks. The result? After installing hooks for Apache Airflow, prek used about 810MB of disk space compared to 1.6GB for pre-commit. That’s roughly half the disk usage.

No Python dependency

One of the things that has always bugged me about pre-commit is that it’s a Python tool. That means you need a Python installation to use it, even if you’re working on a Node.js or Go project. prek ships as a single binary with no dependencies. It doesn’t require Python or any other runtime.

Even better: if your hooks need Python, prek will automatically install the required version for you. No more hassle with your system Python version not matching what the hooks expect.

Parallel execution

pre-commit runs hooks sequentially. prek can run hooks in parallel based on priority. Hooks with the same priority may run concurrently, reducing the end-to-end runtime. This is especially useful when you have multiple independent hooks that don’t need to run in a specific order.

Better CLI experience

prek comes with some nice quality-of-life improvements over pre-commit’s CLI (full list):

• prek run --directory <dir> runs hooks for files in a specific directory. No more piping git ls-files into xargs.
• prek run --last-commit runs hooks on files changed in the last commit.
• prek run [HOOK] [HOOK] lets you select and run multiple hooks at once.
• prek list gives you a nice overview of all configured hooks and their descriptions.
• prek auto-update supports --cooldown-days to avoid picking up brand-new releases immediately — a neat defense against supply chain attacks.

Monorepo support

If you work with monorepos, prek has built-in workspace mode. Each subproject can have its own .pre-commit-config.yaml file, and prek handles running hooks across all of them. This is something pre-commit doesn’t support natively, and it doesn’t seem this will be implemented soon.

Built-in hooks

prek implements some common hooks from pre-commit-hooks natively in Rust (see the list). These are faster than their Python counterparts and can run offline with repo: builtin, which is not available in pre-commit.

Where pre-commit still wins

It wouldn’t be fair to not mention the areas where pre-commit still has the upper hand.

Maturity and ecosystem: pre-commit has been around for over a decade. It has extensive documentation, a massive community, and a proven track record. When something goes wrong, you’re more likely to find an answer on Stack Overflow.

Language support: While prek supports most commonly used languages, some are not yet fully supported for drop-in parity with pre-commit. Check the Language Support page for the current status.

pre-commit.ci: If you use pre-commit.ci for running hooks in CI and auto-fixing pull requests, there’s no equivalent for prek yet. That said, there is a prek GitHub Action available for CI integration.

Battle-tested edge cases: pre-commit has handled just about every obscure configuration and edge case out there. prek is newer and, while it’s already used by projects like CPython, FastAPI, Apache Airflow, and Django, it might not handle every niche scenario yet.

Who’s already using prek?

The adoption list is actually quite impressive for such a young tool. Projects like CPython, FastAPI, Apache Airflow, Ruff, and Home Assistant have either adopted prek or are in the process of switching. That’s a pretty strong signal.

Conclusion

If you’re already using pre-commit and everything works fine, there’s no rush to switch. pre-commit is a solid, battle-tested tool that will continue to serve you well.

However, if you find yourself annoyed by slow hook installations, if you’re working in a monorepo, or if you just like your tools to be fast, prek is absolutely worth trying. The migration path is painless and fully reversible. Give it a spin, see if it works for your setup, and enjoy the speed boost.

The trend of rewriting Python tooling in Rust isn’t slowing down, and prek fits right into this movement alongside Ruff and uv. It’s exciting to see the Python ecosystem getting faster without sacrificing the developer experience we’ve come to expect.