Back to Blog
macOS tutorial system tools

mds_stores High CPU on Mac: When to Wait and When to Fix It

mds_stores eating CPU and disk? It is Spotlight's per-volume indexer. Most spikes are real work that resolves on its own — learn how to tell legitimate indexing from a stuck process, and what actually fixes it.

You open Activity Monitor because your Mac feels sluggish — fans loud, disk light grinding — and the process at the top of the CPU column is mds_stores, often at 100%, 200%, or more. Killing it feels wrong; waiting feels wasteful. Unlike a misbehaving app, this might be legitimate work — or it might be stuck. This guide gives you a clear way to tell the difference, and walks through the fixes that actually help.

Quick Answer

mds_stores is the per-volume worker for Spotlight, the macOS search index. High CPU is usually a real workload: initial indexing after an install or upgrade, a newly mounted external drive, cloud sync churn, or a developer workflow creating thousands of small files. Three signals suggest it is stuck rather than working:

  1. It has been running over 24 hours on the same volume with no progress.
  2. There is no recent trigger — no cloud sync running, no large file copy, no newly mounted drive — yet CPU and disk stay high for hours.
  3. It cycles on the same files repeatedly.

ProcXray’s Open Files panel shows exactly which paths mds_stores is reading right now — the single fastest way to identify what is triggering it. Activity Monitor’s process Inspector can list a process’s open files too, but as a static dialog with no search or history — for sifting through thousands of indexing paths in real time, ProcXray’s panel resolves the diagnosis in seconds.

What Is mds_stores?

mds_stores is one of three processes that make up Spotlight on macOS:

If you see multiple mds_stores processes in Activity Monitor, that is normal — it just means more than one volume is being indexed. A typical idle Mac with a fully built index runs mds_stores at roughly 0–5% CPU. The per-volume model also means an external drive’s mds_stores can spike on its own without affecting the boot volume’s worker.

A note on the percentages: in Activity Monitor, 100% means the equivalent of one full CPU core. On a multi-core Mac, a single process can report well above 100%. So mds_stores at 250% is occupying the equivalent of about two and a half full cores.

The Reframe: Working vs Stuck

This is the most important reframe of this guide. Unlike WindowServer, which is always downstream of some app driving it, mds_stores doing CPU work usually means the indexer is legitimately busy — and legitimate work has a finite endpoint. The diagnostic question is not “what is wrong with mds_stores?” It is:

Is this transient indexing that will finish, or is the indexer stuck?

A short rubric:

This rubric structures the rest of the article: identify the trigger, confirm whether it is finishing, and apply the right fix.

What Triggers mds_stores Spikes

There are six common triggers, roughly in order of how often they come up:

1. Fresh install or macOS upgrade

The first time Spotlight indexes a volume, it has to extract metadata from every file. On a recently-set-up Mac, this can take 30 minutes to several hours, depending on home directory size and how many photos or documents you have. Major macOS upgrades sometimes trigger a partial re-index too.

2. A new external drive, or a large file copy

Each new file needs metadata extraction. Mounting a 1 TB external full of mixed content can keep mds_stores busy for one to several hours. A large copy into your boot volume — say, restoring a folder from backup — has the same effect.

3. Cloud sync churn

This is the single most common cause of “mds_stores never stops”. iCloud Drive, Dropbox, OneDrive, Google Drive, and Box all create, modify, and delete files in the background. Every one of those changes is a file system event Spotlight has to follow. Two specific patterns are notorious: iCloud’s Optimize Mac Storage (which evicts and re-downloads files), and OneDrive’s Files On-Demand (same idea). Each eviction/download cycle re-triggers indexing on the affected file.

4. Dev workflows that create thousands of small files

npm install / yarn install (the dreaded node_modules), Xcode builds writing to ~/Library/Developer/Xcode/DerivedData, git checkout on a large branch, Docker image extracts, and Homebrew updates all generate large bursts of file system events. Spotlight tries to index them all.

5. Time Machine first backup or a large snapshot

Time Machine shares the file system event stream that Spotlight watches. A first-time backup, or a large snapshot operation, can interact with mds_stores in ways that drive both processes up at once.

6. Corrupted index requiring rebuild

After a force-shutdown, kernel panic, APFS volume problem, or a failed disk repair, the Spotlight index can become inconsistent. mds_stores then has to rebuild it from scratch — a process that looks identical to initial indexing but happens out of nowhere.

A few specific apps worth calling out as frequent churn sources: Adobe Creative Cloud sync, Backblaze, Carbon Copy Cloner, and any antivirus that scans on access. If you have one of these running, suspect it first.

How to Tell If It Will Resolve On Its Own

Activity Monitor is the natural starting point, but its open-files view is a static modal — without search or history — and that’s the detail that most often cracks this case: which file paths mds_stores is reading right now, evolving over time.

Step 1: Check whether indexing is enabled

Open Terminal and run:

mdutil -s /

The output is one of:

Repeat the command for each volume (mdutil -s /Volumes/External).

Important: mdutil -s only tells you whether Spotlight indexing is enabled on the volume — it does not report progress or whether indexing is actively running. To answer “is it still working forward?”, combine it with: the disk-read trend in Step 2, whether the file paths in Open Files change over time in Step 3, and whether Spotlight’s own search window still shows an “Indexing…” status bar when you open it.

Step 2: Quick wins in Activity Monitor

CPU tab → sort by CPU and confirm mds_stores is on top. Switch to the Disk tab and sort by Bytes Read. If mds_stores dominates disk reads, it is actively scanning files (which is what indexing looks like). Watch for five minutes — is the CPU trending down, flat, or rising?

Step 3: Identify what it’s indexing, with ProcXray

ProcXray is purpose-built for this kind of cross-resource diagnosis:

For more on the gaps Activity Monitor leaves for this kind of debugging, see ProcXray vs Activity Monitor.

Step 4: A/B test by removing suspected triggers

Once you have a hypothesis, eject external drives one at a time. Pause cloud sync apps. Quit your build tools. After each change, watch mds_stores for a minute. A clear drop confirms the cause without rebooting or disrupting your full session.

Step-by-Step Fixes

Apply these in order — cheapest, least disruptive first.

1. Wait 30 minutes to 2 hours on first observation

The single most overlooked fix. Most indexing finishes in this window. Plug the Mac into power and let it run. Coming back to a Mac that has completed its index is almost always the correct outcome.

2. Add the culprit folder to Spotlight Search Privacy

System Settings → Spotlight → Search Privacy → drag the folder in. This stops Spotlight from indexing it. The folders most worth excluding:

The tradeoff: those files will not appear in Spotlight search. For build artifacts and node_modules, this is almost always the right call.

3. Pause cloud sync temporarily

If the Open Files panel showed mds_stores reading from an iCloud, Dropbox, OneDrive, or Google Drive folder, pause that app. If mds_stores settles within a few minutes, you have confirmed the cause. For a long-term fix, either accept the indexing cost or exclude the cloud folder from Spotlight via Search Privacy. If iCloud’s “Optimize Mac Storage” is enabled and you have the disk space, consider turning it off — the constant evict/re-download cycle is a frequent root cause of loops.

4. Disable indexing on a specific volume

For external drives you do not search through Spotlight (e.g., a scratch drive, a media archive). Do not disable indexing on a Time Machine backup disk — Time Machine relies on Spotlight indexing of that volume.

sudo mdutil -i off /Volumes/External

Re-enable later with sudo mdutil -i on /Volumes/External.

5. Force a clean rebuild when the index is corrupt

If mdutil -s reported “unknown indexing state”, or if you have ruled out every trigger and mds_stores keeps spinning, erase and rebuild the index:

sudo mdutil -E /

Expect 30 minutes to several hours of high CPU and disk while the index rebuilds — that is the rebuild itself, not a problem. Use this when you have confirmed corruption, not as a first reflex.

6. Last resort: kill mds_stores directly

macOS will respawn it cleanly within seconds. This does not fix the trigger, but can interrupt a runaway loop long enough to investigate. Use Activity Monitor’s “Force Quit”, or:

sudo killall mds_stores

Not recommended: permanently disabling Spotlight with sudo mdutil -a -i off. You lose Spotlight search, Mail search, and any app that depends on the underlying metadata APIs. Almost never the right fix — exclude noisy folders via Search Privacy instead.

For broader performance triage when mds_stores is not the only suspect, see how to fix a Mac running slow by killing the right processes.

FAQ

Can I kill mds_stores safely?

Yes. macOS automatically respawns it within seconds. Killing it interrupts whatever it is doing, but does not damage the index or your data. The catch: if you kill it and the same workload re-triggers it immediately, you have not fixed anything — you have just confirmed the cause is persistent and needs a real fix from the list above.

How long should normal indexing take?

Initial index on a recently-set-up Mac: 30 minutes to 2 hours typical, up to 4–6 hours on very large home directories. A newly mounted 1 TB external drive: roughly proportional to file count, often 1–4 hours. Indexing after a cloud sync burst: minutes. Sustained activity past 24 hours on a stable file set is unusual and points at either a stuck process or a runaway churn source.

Why does mds_stores keep restarting indexing on the same files?

Almost always a cloud sync app or backup tool repeatedly touching the same files. iCloud Drive’s Optimize Mac Storage is a frequent offender — it evicts and re-downloads files, and each cycle re-triggers Spotlight on the affected file. Check System Settings → [Your Name] → iCloud → iCloud Drive → Optimize Mac Storage. Disabling it (if you have the disk space) often resolves the loop.

Should I disable Spotlight permanently?

No, unless you have a very specific reason and do not use Spotlight, Mail, or any system-search feature. Many apps rely on the underlying metadata APIs — disabling Spotlight breaks more than just the magnifying-glass icon. Excluding noisy folders via Search Privacy gives you most of the benefit at almost none of the cost.

Why is mds_stores using disk but barely any CPU?

Indexing is largely I/O-bound. mds_stores spends most of its time reading file contents from disk, with short CPU bursts to parse metadata. High disk + low CPU is the normal indexing signature. If CPU is also high, the indexer is hitting many small files — typical of node_modules, mailboxes, or git objects.

Sources and References

Download ProcXray free → — see exactly which files mds_stores is indexing right now. macOS Sonoma+, Apple Silicon & Intel.