nix-index-database: Weekly Prebuilt Indexes for nix-locate

The problem: nix-locate without the wait

nix-index builds a database of file paths in the nix store so you can search for which package provides a given binary. Building that index locally means scanning thousands of store paths, which takes time and disk space. nix-index-database solves this by publishing a prebuilt database for the nixos-unstable channel, refreshed weekly. The target user is anyone on nixos-unstable who wants nix-locate to work out of the box, or who wants shell command-not-found to resolve unknown commands to nix packages. The README positions it as a drop-in replacement for the manual index step, and the weekly release cadence matches the rolling nature of unstable.

Two database variants: full and small

The project ships two database variants. The full database, packaged as nix-index-with-db, contains all indexed files, including headers and libraries. The small database, nix-index-with-small-db, filters to files under /bin/ directories only. The small variant downloads faster and uses less memory, at the cost of not finding non-executable files. The README shows how to switch: override programs.nix-index.package with the small package. That choice matters if you search for headers or libraries. If you only care about binaries, the small variant is the sensible default. The existence of two variants acknowledges that the full database is heavy, but the README does not give sizes, so you cannot judge the trade-off numerically.

How the modules wrap nix-index

The repository provides NixOS, nix-darwin, and home-manager modules. Each module adds a wrapper around nix-index so that nix-locate automatically uses the database from this repository. The wrapper replaces the plain nix-index package, and the README warns not to include nix-index in environment.systemPackages or home.packages, because that would conflict with the wrapper. The home-manager module also enables shell command-not-found integration when you set programs.nix-index.enable = true. The mechanism is straightforward: the wrapper points nix-index at the bundled database file, so you do not need to run nix-index yourself. The module structure mirrors typical nix-community patterns, with separate entry points for each system type.

Getting it running: flake inputs and modules

The README gives concrete flake configurations. For NixOS, you add nix-index-database as an input, set nix-index-database.inputs.nixpkgs.follows = "nixpkgs", and include nix-index-database.nixosModules.default in your modules list. The same pattern applies to nix-darwin with darwinModules.nix-index, and to home-manager with its module. After that, you call nix-locate as usual. The README also shows an ad-hoc download function that fetches the latest index file directly from GitHub releases, placing it in ~/.cache/nix-index and symlinking it as files. That ad-hoc path bypasses the modules entirely, useful for non-NixOS systems or for quick manual updates. The function maps arm64 to aarch64 for the filename, so it works on Apple Silicon.

A hard requirement: Nix 2.18 or newer

The packages use unsafeDiscardReferences to skip nix store checks, and the README states that on older Nix versions these packages might fail. That is a concrete compatibility constraint. On an older Nix version, the packages may fail to install. This is a real limitation because many users run stable Nix or older distributions. The requirement is not optional; it is tied to a specific Nix feature. Before adopting, check your Nix version with nix --version. The project lists Nix 2.18 or newer as a requirement. The README does not explain why unsafeDiscardReferences is needed, but it is likely to avoid the store path checks that would otherwise reject the prebuilt database.

Limitations: channel lock, weekly refresh, and shell scope

The database is built for nixos-unstable only. If you use nixpkgs stable or a custom fork, the index will not match your store, and nix-locate will give wrong or missing results. The weekly refresh means new packages appear in the index up to a week after they land in unstable, so very recent additions may be absent. The command-not-found integration only works if your shell is managed by home-manager, as the README states. On NixOS without home-manager, you get nix-locate but not the shell hook. These are not bugs, but they narrow the audience. The module conflict warning is another constraint: you must remember not to install nix-index separately, which is easy to forget if you have an existing configuration.

Alternative: building nix-index yourself

The direct alternative is to run nix-index locally against your own nixpkgs checkout. That is what nix-index-database automates away. The difference in approach is control: building your own index matches your exact nixpkgs revision, including stable channels or custom overlays, and updates whenever you want. The cost is time and disk space, which the prebuilt database avoids. Another alternative is the nix-index project itself, which provides the tool but not the data. nix-index-database is a companion that supplies the data. If you need a custom channel, you cannot use this database, and the local build is the only path. For most nixos-unstable users, the prebuilt database is the practical choice, but the alternative exists for those who need precision.

Maintenance and license

The repository is under the MIT license, which permits reuse with minimal restrictions. The project is actively maintained, with weekly releases dated every Saturday or Sunday, and the last push is recent. The maintainer is listed as @Mic92, a known figure in the nix-community. The release names encode the date and time, like 2026-08-23-033710, and the ad-hoc download uses the latest release tag. Upgrade cost is low: because the database is a package, updating your flake inputs pulls the new version. The module configuration is stable across releases, so no config changes are needed. The main maintenance burden is keeping your Nix version above 2.18 and remembering not to duplicate nix-index in your package list. The weekly cadence means you get fresh data automatically, but you must accept the channel lock.

Editorial conclusion

Adopt nix-index-database if you run nixos-unstable and want nix-locate to work immediately without building an index yourself. Skip it if you need a custom channel or prefer to control index freshness, since the database only tracks nixos-unstable and updates weekly. Before adopting, verify your Nix version is 2.18 or newer, because the packages rely on unsafeDiscardReferences, and check that your shell's command-not-found integration works with your configured shell in home-manager.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes