Pacman can’t install a single package from the AUR, and that is the whole answer to most yay vs pacman searches. Pacman handles the official Arch repositories. Yay and paru wrap pacman and add the Arch User Repository on top, so you don’t pick one instead of pacman. You pick one to run alongside it.
The harder choice is yay vs paru. We built both AUR helpers from source and from their prebuilt -bin packages on the same Arch Linux VM, timed the same commands under all three tools, and pushed paru’s build onto a 2 GB VM to find where it breaks. Two results surprised us: paru-bin installs cleanly but no longer starts, and paru’s own build needs about 3.4 GiB of RAM. If you only want the command list, the pacman and yay cheat sheet covers that. This page is about which tool to run.
Current as of October 2026.
Yay vs pacman vs paru at a glance
Every number below comes from one VM and one test session. The method is in the next section.
| pacman | yay | paru | |
|---|---|---|---|
| Installs from | Official repos only | Repos + AUR | Repos + AUR |
| Written in | C | Go | Rust |
| Version tested | 7.1.0 | 13.0.1 | 2.1.0 |
| Latest release | Ships with Arch | 2026-06-19 | 2025-07-08 |
| Prebuilt -bin package | n/a | yay-bin works, 7.9 s to install | paru-bin broken (libalpm.so.15) |
| Build from source | n/a | 27 s, 282 MiB peak RAM | 3 m 45 s to 4 m 20 s, 3.4 GiB peak RAM |
| Build deps left installed | n/a | go, 226 MiB | rust + LLVM, 535 MiB |
| Builds on 2 GB RAM | n/a | Yes | No (OOM), yes with LTO off |
-Ss nginx median | 0.16 s, 39 results | 1.55 s, 193 results | 0.87 s, 193 results |
| AUR install (downgrade) | Not supported | 7.16 s | 7.29 s |
| Default before building | n/a | Asks which diffs to show | Prints the full PKGBUILD for review |
| Run with sudo | Required for installs and removals | Warns, half-installs, fails | Refuses up front |
For most people, yay-bin is the one to install. It is maintained, it installs in seconds, and the binary actually runs. Paru is the better pick if you want PKGBUILD review forced on you, but you will have to build it yourself right now.
How we tested
All three tools ran on a single Proxmox VM: Arch Linux fully upgraded on kernel 7.2.8, 4 vCPU (host CPU type), 4 GB RAM and the 512 MB swapfile our Arch template ships with. Build times are wall clock for makepkg -si under /usr/bin/time -v, with the Go and Cargo caches wiped first, and peak RAM is the max resident set size that tool reports, which is the largest single process in the build (rustc or go), not total system memory. Command timings are the median of five runs each. The AUR install test removed the package and its dependencies between three runs per helper. For the low-memory test we cut the same VM to 2 GB and kept the swap. To build a matching VM, the archinstall walkthrough gets you a base system in a few minutes.
Every build used Arch’s stock /etc/makepkg.conf, which matters later. Its OPTIONS line includes debug and lto.
1. pacman
Pacman is the package manager, and nothing on Arch replaces it. Yay and paru both link against its library, libalpm, and hand every repo transaction back to it. What pacman won’t do is talk to the AUR. Ask it for an AUR package and it says so plainly:
sudo pacman -S yay-binThe AUR is not one of its repositories, so the target doesn’t exist as far as pacman’s concerned:
error: target not found: yay-binYou can still use the AUR with pacman alone. You clone the package’s git repo, build it with makepkg, and makepkg calls pacman -U on the result. That is exactly how every AUR helper gets bootstrapped, so you will do it at least once anyway. Install the build tools first:
sudo pacman -S --needed git base-develThen clone and build. Here it is yay-bin, which took 7.9 seconds on our VM:
git clone https://aur.archlinux.org/yay-bin.git
cd yay-bin
makepkg -siDoing that by hand for every AUR package gets old fast. You also lose dependency resolution across AUR packages and an easy upgrade path, since pacman -Syu never checks the AUR for newer versions. Those are the gaps a helper fills. To see what you’ve installed from outside the repos, pacman -Qm lists every foreign package.
“Running makepkg as root is not allowed”
Prefixing makepkg with sudo fails straight away:
==> ERROR: Running makepkg as root is not allowed as it can cause permanent,
catastrophic damage to your system.Run makepkg as your normal user. It calls sudo itself when it’s time to install, so a fresh install needs a regular sudo user before any AUR work (one of the first Arch post-install steps).
2. yay
Yay has twice paru’s votes on the AUR (2,653 against 1,259), and it is the one still shipping releases. Version 13 landed in June 2026 with a Lua config file and install hooks, and a point release followed two days later. Its default flow asks every question up front, then builds without stopping.
The binary package is the quick route. It’s the yay-bin build from the pacman section above, and it ran first time:
Notice the -debug packages in that pacman -Qm list. That is the debug option in the stock makepkg.conf, and makepkg -si installs the debug package alongside the real one.
Building from source takes longer but is not painful. The yay package pulls Go in as a make dependency:
git clone https://aur.archlinux.org/yay.git
cd yay
makepkg -siThat build finished in 27 seconds and peaked at 282 MiB of RAM. It also left Go installed (226 MiB) plus a 22.9 MiB yay-debug package. Neither is needed once yay runs, so drop them. The -debug package only exists when debug is in your makepkg.conf, so leave its name out if pacman -Q doesn’t list it, or pacman stops with “target not found”:
sudo pacman -Rns go yay-debugPacman freed 249.34 MiB on our VM, and yay still reported in afterwards:
yay v13.0.1 - libalpm v16.0.1The diff menu, and switching it off with init.lua
Before it builds anything, yay asks which PKGBUILD diffs you want to read:
==> Diffs to show?
==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4)Answer A on anything new to you. A PKGBUILD is a shell script that runs on your machine, and the AUR does not vet it. If you’d rather skip the prompt for scripted installs, --answerdiff None --answerclean None does it per command. Yay 13 also reads a Lua file at ~/.config/yay/init.lua. One line turns the diff menu off for good:
mkdir -p ~/.config/yay
echo 'yay.opt.diff_menu = false' | tee ~/.config/yay/init.luaWith that file in place, our next yay -S downgrade skipped the diff prompt entirely. It still asked about clean builds, because the build files were already cached. The yay Lua manual lists the other options and the hook events v13 added.
“Avoid running yay as root/sudo”
Yay prints that warning when you run sudo yay -S downgrade, but it does not stop. Makepkg refused to run as root on the first step (downloading sources), and yay carried on anyway. It installed the repo dependencies (fzf and pacman-contrib) as root, hit the same makepkg check a second time, and gave up:
==> ERROR: Running makepkg as root is not allowed as it can cause permanent,
catastrophic damage to your system.
-> error making: downgrade-exit status 10
-> Failed to install the following packages. Manual intervention is required:
downgrade - exit status 10The AUR package never installed, but its two dependencies stayed behind, marked as installed for another package. Rerun yay as your own user, and clean up orphans with yay’s own command:
yay -YcOn our VM it found both strays plus the Rust toolchain left from a paru build, 540.29 MiB in total:
Packages (8) compiler-rt-23.1.1-1 fzf-0.74.4-1 libgit2-1:1.9.7-1 lld-23.1.1-1 llhttp-9.3.1-1 llvm-libs-23.1.1-1 pacman-contrib-1.13.1-1 rust-1:1.98.1-2
Total Removed Size: 540.29 MiBWhere yay falls short: it’s the slowest of the three at searching (1.55 s for -Ss nginx, against 0.87 s for paru) and uses the most memory (about 77 MiB peak, against paru’s 67 MiB). You will never notice either at a terminal. Yay’s -Gc also just downloads the PKGBUILD, while paru’s prints the AUR comments. For a longer walk through yay’s flags, see the yay install guide.
3. paru
Paru comes from Morganamilo, yay’s second-biggest contributor (730 commits to yay), and it is the stricter of the two. It shows you the PKGBUILD before it builds, refuses to run as root, and has extras yay lacks, like AUR comments in the terminal and a --chroot build mode. The catch is maintenance pace. The last paru release is 2.1.0 from July 2025, and the last commit to the repo was a batch of translation merges in January 2026.
That gap is why the prebuilt package is broken. In late 2025, pacman bumped libalpm’s shared-library version to 16. The source package was rebuilt in December 2025, but paru-bin is still the July 2025 binary linked against libalpm.so.15. Pacman installs it without complaint, because the package only declares libalpm.so>=14. Then it fails the first time you run it:
“error while loading shared libraries: libalpm.so.15”
If you see that line, remove paru-bin and build paru from source instead, which links against the libalpm your system has:
sudo pacman -Rns paru-bin paru-bin-debugThe source build uses the same three steps as yay:
git clone https://aur.archlinux.org/paru.git
cd paru
makepkg -siExpect it to take a while. Makepkg pulled 535 MiB of build dependencies (Rust, LLVM libraries, lld, compiler-rt), and Cargo compiled 219 crates. Our two runs took 3 m 45 s and 4 m 20 s, and the slower one included a stalled crate download. Both peaked at about 3.4 GiB, because paru’s release profile builds with full LTO and a single codegen unit. Once it is done, it reports the right library:
paru v2.1.0 - libalpm v16.0.1Now remove the toolchain and the debug package (same caveat: skip paru-debug if it isn’t installed), which freed 535.93 MiB here:
sudo pacman -Rns rust paru-debugparu build killed on a 2 GB VM: “could not compile paru (bin “paru”)”
With 2 GB of RAM and 512 MB of swap, the same build died at the final link step after 1 m 53 s:
error: could not compile `paru` (bin "paru")
Caused by:
process didn't exit successfully: `rustc --crate-name paru --edition=2021 src/main.rs ... -C opt-level=3 -C lto -C codegen-units=1 ...` (signal: 9, SIGKILL: kill)
==> ERROR: A failure occurred in build().
Aborting...The kernel log names the culprit:
Out of memory: Killed process 6919 (rustc) total-vm:2758728kB, anon-rss:1598132kB, file-rss:16kB, shmem-rss:0kB, UID:1000 pgtables:4656kB oom_score_adj:0Cargo lets environment variables override a crate’s release profile, so you can switch LTO off without editing anything. On the same 2 GB VM, this built cleanly in 2 m 11 s and peaked at 1.04 GiB:
CARGO_PROFILE_RELEASE_LTO=false CARGO_PROFILE_RELEASE_CODEGEN_UNITS=16 makepkg -siWhat you give up is binary size: 10.8 MB instead of 7.9 MB. It started and reported libalpm v16.0.1 like the LTO build. On a small VM or an old laptop, that’s the cheapest way to get paru today.
Review by default
Paru’s default flow is the reason people switch. It lists the repo and AUR packages it will install, asks to proceed to review, then prints every file in the package before anything builds:
Yay shows diffs by default, but it only opens the full PKGBUILD if you add --editmenu. Paru also reads AUR comments for you, which is often where you learn a package is broken before you try it:
paru -Gc downgradeIts orphan cleanup is paru -c, the equivalent of yay -Yc. We marked fzf as a dependency to test it, and paru removed fzf plus a leftover pacman-contrib (5.60 MiB) in one go. paru -Ps has one quirk: it lists the -debug packages as “packages not in the AUR”. That’s harmless, and it goes away once you remove them.
Yay vs paru speed on the same commands
Speed should not decide this. Every gap below is under a second and a half, and the one job that takes real time is a tie. Medians of five runs:
| Command | pacman | yay | paru |
|---|---|---|---|
-Ss nginx (search) | 0.16 s | 1.55 s | 0.87 s |
-Si nginx (repo package info) | 0.15 s | 0.36 s | 0.34 s |
-Syu with nothing to update | 1.09 s | 1.80 s | 1.89 s |
-Qua (AUR updates) | n/a | 0.85 s | 0.83 s |
Install downgrade from the AUR | n/a | 7.16 s | 7.29 s |
| Peak RAM during a search | 56 MiB | 77 MiB | 67 MiB |
Pacman’s search returned 39 results for nginx. Both helpers returned 39 repo results plus 154 AUR packages, so they do more work per search than pacman does. The AUR install is a dead heat, which makes sense: makepkg does the building for both. If you also run a GUI store, our roundup of AUR package managers covers the front ends that sit on top of these.
Which one to install
You will keep pacman no matter what, and it stays the tool for the official repos. If you only ever install from core and extra, you do not need a helper at all. For the AUR, pick by situation:
- Most desktops and laptops: install yay-bin. It’s the actively maintained helper, its binary runs against current libalpm, and it was set up in 7.9 seconds.
- You want review forced on every install: build paru from source. Plan on about 4 minutes and 3.4 GiB of free RAM, then remove the 535 MiB toolchain afterwards.
- Paru on a 2 GB machine: build it with
CARGO_PROFILE_RELEASE_LTO=false, which fit in 1.04 GiB. - Skip for now: paru-bin. It installs and then cannot find libalpm.so.15.
Whichever you pick, run it as your own user and read the PKGBUILD of anything new. The Arch wiki’s AUR page is blunt about it: AUR packages are user-produced, not thoroughly vetted, and any use is at your own risk. That holds for yay and paru equally, because both just hand the PKGBUILD to makepkg.
