Spotlight's Hidden Index: The .Spotlight-V100 Folder Nobody Checks

If mds_stores or mdworker has ever shown up pinning a CPU core in Activity Monitor for reasons you couldn’t explain, or your external drive has a folder called .Spotlight-V100 you’ve never opened, this is the same subsystem causing both problems.

What it actually is

Spotlight — the search feature behind Cmd+Space — maintains a persistent index of nearly every file’s metadata and, for many file types, its actual content, so search results return instantly instead of scanning your disk live. That index lives in a hidden folder on every mounted volume:

sudo du -sh /.Spotlight-V100
sudo du -sh /Volumes/*/. Spotlight-V100 2>/dev/null

On a primary internal volume with years of files, this routinely runs 5–15 GB. It’s normally invisible because Finder hides dotfiles by default and the folder sits at the volume root, not somewhere you’d browse to.

Why it sometimes balloons or spins a CPU core

Two related failure modes cause the complaints people actually search for:

A stuck or repeating reindex. After a crash during indexing, an unexpected shutdown, or certain macOS updates, Spotlight can get into a state where it keeps restarting its index from scratch instead of finishing and going idle. You’ll see mds_stores or mdworker_shared consuming significant CPU continuously, often for hours, well past what a normal reindex takes.

# Check reindexing progress/status for the main volume
mdutil -s /

If this reports indexing is in progress and has been for an unreasonable amount of time, a stuck reindex is a reasonable suspicion.

A single misbehaving file type. Certain third-party apps ship metadata importer plugins that can crash repeatedly on a specific file, causing Spotlight to retry indexing that file indefinitely. This is less common but produces the same symptom: sustained CPU usage with no end in sight.

Fixing it: rebuild the index

The fix for both failure modes is the same — tell Spotlight to discard its current index and start clean:

sudo mdutil -E /

This erases and rebuilds the index for the root volume. Expect elevated CPU and disk activity for anywhere from twenty minutes to a few hours afterward depending on how much content you have, followed by things going quiet once the fresh index completes. Search results (Spotlight, and anything that relies on it, including Finder’s own search) will be incomplete during this window.

For a specific external volume instead of the whole system:

sudo mdutil -E /Volumes/YourDriveName

Turning it off entirely, if you never use Spotlight search

Some people genuinely never use Cmd+Space and would rather not pay the ongoing indexing cost at all. Spotlight can be disabled per-volume:

sudo mdutil -i off /

This stops indexing and lets the existing .Spotlight-V100 folder be reclaimed over time, though it won’t necessarily delete it immediately. Worth knowing the trade-off before doing this system-wide: a lot of macOS features quietly depend on Spotlight beyond the search bar itself — Time Machine’s smart exclusions, Finder’s search and “Get Info” file previews, and third-party app launchers like Alfred and Raycast that build on Spotlight’s index rather than maintaining their own. Disabling it is a bigger decision than it looks; most people are better served by fixing a stuck index (above) than turning the feature off.

Where this fits relative to everything else on this blog

Unlike the build caches and package manager stores covered elsewhere here, Spotlight’s index is one of the few categories that’s actually doing something for you continuously, not just sitting there as accumulated byproduct — the trade-off is closer to the one covered in the Time Machine local snapshots guide than to something like DerivedData, which serves zero purpose once written.

Run mdutil -s / yourself the next time mds_stores looks suspicious in Activity Monitor — it’s free and it works. DevCruft, a free Mac app for developers we’re building, is being designed to show Spotlight’s index size on a disk map alongside everything else, so it’s a known quantity instead of an invisible dotfile you only think to check when a CPU core is already pinned. Join the waitlist if you’d like to know when it launches.

For the other invisible, easy-to-miss space consumer that hides at the system level rather than in an app-specific folder, see what “System Data” actually contains.