The Nix store never deletes anything until you tell it to

The Nix store is append only by design. Every version of every package you have ever installed or built stays there, kept alive by profile generations, and nothing is removed until you explicitly collect garbage. That is what makes rollbacks work and what makes the folder large.

Measure it

du -sh /nix 2>/dev/null
nix path-info --all --size 2>/dev/null | sort -k2 -n | tail -20
nix-env --list-generations

Garbage collection, and what keeps things alive

A path in the store is kept if something references it: a profile generation, a result symlink from a build, a running process, or a GC root. Collecting garbage removes only what nothing references, so the first step is usually removing old generations rather than running the collector.

nix-env --delete-generations old
nix-collect-garbage -d          # deletes old generations and collects
nix store gc                    # newer command, same idea

The result symlinks nobody remembers

Every nix build leaves a result symlink in the directory you ran it from, and each one is a GC root that pins its entire closure. On a machine used for development there are dozens scattered across project folders, holding on to build outputs from months ago.

find ~ -maxdepth 6 -name 'result' -type l 2>/dev/null | head -20
nix-store --gc --print-roots | head -20

Being deliberate about it

1. List generations and decide how far back you actually need to roll back.
2. Delete generations older than that, per profile.
3. Remove stale result symlinks from project folders.
4. Run the collector, then measure /nix again.

On a shared or long lived machine this routinely reclaims tens of gigabytes, and unlike most cleanups it has an explicit safety model: if something still needs a path, the collector will not remove it.

The same idea of a store that projects link into, rather than a cache, appears in pnpm's store, where deleting rather than pruning breaks existing installs.