Mac maintenance
What Is the 'mds' Process on Mac and Why Is It Eating CPU?
The mds process on Mac is Spotlight's metadata server. Here's why it spikes to 100% CPU, when that's normal, and how to actually fix it.
You open Activity Monitor because the fans on your MacBook are screaming. Sort by CPU. Right at the top, using 187% of your CPU and 4 GB of RAM, sits a process called mds_stores. You don’t remember installing it. You can’t quit it from Force Quit. Closing apps doesn’t help. After 20 minutes, it’s still up there.
mds_stores (and its sibling mds) is Apple’s metadata server, the heart of Spotlight. It’s not a virus, it’s not optional, and most of the time it’s doing legitimate work that you actually want done. The catch: “most of the time” hides cases where it’s stuck, broken, or burning effort on something you don’t care about. Knowing the difference is the difference between waiting it out and intervening.
What mds and mds_stores Actually Do
Spotlight’s metadata system is implemented by a few cooperating processes:
- mds — the metadata server, owns the overall indexing strategy
- mds_stores — handles writing to and reading from the actual on-disk indexes
- mdworker — child workers spawned to extract metadata from individual files
When Spotlight’s index needs updating — because new files were created, existing files changed, or a full reindex was triggered — mds decides what to do, mdworker instances actually open files and pull metadata, and mds_stores commits everything to the database at /.Spotlight-V100/.
These processes run as the system, not as you. Force Quit can terminate them, but launchd immediately respawns them. They’re meant to run continuously.
When High CPU Is Normal
Several scenarios where mds_stores legitimately uses a lot of CPU and you should just let it finish:
Right after a macOS upgrade
A major macOS install (Sonoma, Sequoia, etc.) triggers a full reindex of the boot drive. Multi-hour activity is normal on a heavily-used Mac.
After connecting a new external drive
Plugging in a 4 TB external drive triggers Spotlight to index everything on it (unless you mark it Spotlight-private first). Hours of indexing is expected.
After restoring from a Time Machine backup
The restored data needs to be reindexed from scratch.
After a large file change
If you just downloaded 200 GB of files, dragged a giant folder, or extracted a huge archive, expect indexing activity proportional to the change.
In any of these cases, the right move is patience plus checking that real work is happening. Disk activity in Activity Monitor’s Disk tab tells you whether indexing is making progress. If mds_stores is reading at 100+ MB/s, it’s actually doing work.
When High CPU Is Not Normal
The cases that warrant intervention:
mds_stores pegged for days
A normal reindex finishes. Pegged for 48+ hours suggests mds_stores is stuck on something it can’t process — usually a file that crashes its importer, or a directory it’s looping on.
High CPU with no disk activity
Real indexing involves reading files. If mds_stores is at 100% CPU but disk reads are near zero, the process is spinning on something internal — usually a corrupt index file.
High CPU on a Mac that’s been idle for ages
A new Mac doing a first-time index for hours: normal. A 2-year-old Mac that hasn’t had major changes spending a day re-indexing: not normal.
Memory growing without bound
mds_stores consuming 8+ GB of RAM and climbing usually means an importer is leaking memory or a corrupt index is causing endless retries.
Diagnostic Steps
A quick triage:
mdutil -s /
Tells you whether indexing is enabled and (if reindexing) gives an estimated time remaining. If it says “Indexing enabled” with no estimate, indexing is “current” and mds_stores shouldn’t be busy.
sudo fs_usage -w -f filesys mds_stores
Shows what files mds_stores is currently reading and writing in real time. If you see it accessing the same file or directory repeatedly, that’s the loop.
sudo opensnoop -n mds_stores
Similar but cleaner output: just the files being opened by mds_stores. Lets you spot if a specific file or folder is causing trouble.
For Activity Monitor, double-click mds_stores in the process list, then click “Open Files and Ports” — you can see what it has open right now.
Common Causes of Stuck mds_stores
Several recurring patterns:
Corrupt index database
/.Spotlight-V100/ has internal consistency requirements. A botched shutdown, a disk error, or a specific file that triggers an importer bug can leave the database in a state where mds_stores keeps trying to recover and failing.
Fix: rebuild the index with sudo mdutil -E /. Several-hour reindex follows but completes.
A file an importer can’t handle
A specific PDF, Word doc, or other file might crash the importer that tries to extract metadata from it. The importer respawns and tries again. Forever.
Fix: identify the bad file using fs_usage or opensnoop, then either delete it, exclude its folder from Spotlight, or move it elsewhere temporarily.
Network volume that vanished
If mds_stores was indexing a network share when the network dropped, it can spin trying to reach the unreachable share. Common with external drives that go to sleep, NFS mounts, or SMB shares.
Fix: unmount the affected volume cleanly, or restart mds:
sudo killall mds mds_stores
launchd will respawn them.
Time Machine snapshot mounted
If you mounted a Time Machine backup snapshot to browse, Spotlight may try to index it. This can also happen with disk images you’ve left mounted.
Fix: unmount the snapshot or disk image.
Containerized app sandboxes
Sometimes apps create directories with millions of tiny temporary files (Docker, certain dev tools, cache directories). Spotlight can spin trying to index them all.
Fix: add the offending directory to Spotlight’s privacy exclusions in System Settings → Spotlight → Search Privacy.
node_modules directories, build directories, and Docker volumes to Spotlight Privacy exclusions. They're large, churn constantly, and you don't actually search inside them.Restarting the Daemons
If you suspect mds_stores is stuck rather than legitimately busy, restart the family:
sudo killall mds_stores mdworker mds
After a few seconds, launchd brings them back. They’ll resume indexing from a clean slate, often skipping past whatever was causing the loop.
This is mostly harmless — at worst you lose a few minutes of in-progress indexing work, which gets redone on resume. It’s the right first move for “stuck” symptoms.
Full Reindex via mdutil -E
When the index database itself seems corrupt:
sudo mdutil -E /
This wipes the index for the boot volume and starts over. Time required varies — typically 30 minutes to several hours depending on data volume.
For all volumes:
sudo mdutil -E -a
After running this, expect heavy mds_stores activity for the duration. Don’t run it on battery if you can avoid it; charging power lets the system index without throttling.
Disabling Indexing Entirely
If Spotlight is more trouble than it’s worth on a specific volume (rare but happens for, say, a dedicated video scratch drive):
sudo mdutil -i off /Volumes/ScratchDrive
This stops mds_stores from indexing that volume. Search won’t return content from it, but disk and CPU stop being affected.
For the boot volume specifically, disabling indexing is a heavy hammer — Cmd+Space search becomes very limited, app launch from Spotlight may get slower, and many apps that depend on metadata will lose features. Don’t do this casually.
To re-enable:
sudo mdutil -i on /Volumes/ScratchDrive
There’s a faster waySweep does this kind of cleanup automatically. Try Sweep free →
Spotlight Privacy as a Permanent Fix
For folders that consistently confuse Spotlight or that you don’t need indexed:
- System Settings → Spotlight → Search Privacy
- Click + to add folders or volumes
- They’re permanently excluded until you remove them
Common candidates:
~/Library/Caches— these change constantly, low search value~/Library/Developer— Xcode’s derived data, build outputs- VM disk image directories — internal structure of Parallels/VMware images
- Cloud storage cache directories (Google Drive, OneDrive) — already searchable from those apps’ search bars
- Backup destinations and scratch drives
After adding privacy paths, mds will purge those paths from the index over a few minutes. CPU usage typically drops noticeably.
When It’s Not mds After All
Sometimes mds_stores looks high but a different process is the actual hog. Check:
- mdworker — child workers, can spike during heavy import. Multiple
mdworkerprocesses running simultaneously is normal. - cloudd — iCloud sync; sometimes mistaken for Spotlight activity
- photoanalysisd — Photos app’s face/scene recognition, can run for hours after a library update
- PhotosLibraryService — different Photos-related work
If your CPU spike is from a process whose name starts with “photo,” that’s unrelated to Spotlight. Photos has its own background analysis daemons.
Why mds Exists at All
It’s worth a moment on philosophy. Spotlight is one of the things macOS does that most other operating systems don’t, and it’s because Apple invests CPU and disk into the index so search can be instant later. Without mds_stores, Cmd+Space wouldn’t be the launch tool it is. Searches would either be slow or limited to filenames only.
The trade-off is that mds_stores exists, runs in the background, and occasionally needs human attention. The alternative — no metadata indexing — would mean a slower, less searchable Mac.
For most users, mds_stores is invisible 99% of the time. The 1% where it’s not, knowing what it does and the basic levers (rebuild, restart, exclude) is enough to handle nearly everything that goes wrong.