Is Spotlight wearing down your SSD? Evidence from Sequoia and Tahoe

If you owned a Mac on macOS Sequoia in 2024 and watched the "Bytes Written" line in Disk Utility climb hundreds of gigabytes a day with the lid closed, you were not imagining it. Spotlight's indexer briefly turned into one of the largest sources of unnecessary SSD writes on the platform. Most people noticed only because their machines started sounding warmer; a smaller group noticed because their SMART counters started climbing fast enough to matter.

The bug has been quieter on Tahoe 26, but the underlying mechanic — mds_stores rewriting its index aggressively when something upstream is misbehaving — is still in the code. This post explains what actually happens, how to measure it on your own machine, and what to do if your numbers look wrong.

What "SSD wear" actually means

Every NAND cell in an SSD has a finite number of program/erase cycles. Modern Mac SSDs are rated for somewhere between 600 and 1500 total drive writes over their lifetime; that translates to writing the entire capacity of the drive roughly that many times before the controller starts retiring cells. The number is large enough that most users will replace the laptop long before they hit it.

The Sequoia bug was alarming not because anyone burned out a drive overnight, but because the rate jumped by an order of magnitude. Notebookcheck reported Mac users seeing TB-per-day write totals where their normal baseline was tens of GB. On a 256 GB internal drive, sustained writes at that rate would chew through the rated endurance in months instead of years.

How to read your own counters

You do not need third-party tools for the first measurement. Open Terminal and run:

iostat -d disk0 1 5

The columns labelled KB/t and MB/s show write throughput in real time. Watch them for a minute. A healthy idle Mac should sit near zero except for occasional bursts. If you see a sustained few-MB/s write rate with no app open, something background is busy — usually mds_stores, sometimes a sync client.

For lifetime totals, the easiest path is smartctl from the Homebrew smartmontools package:

brew install smartmontools
sudo smartctl -a disk0

Look at Data Units Written. Each unit is 512 bytes on most controllers, so multiply by 512 and divide by 1e12 to get TB. Compare it to the drive's age in days; you now know your average daily write rate. If it is in the tens of GB you are normal; if it is in the hundreds, something is wrong.

Linking the writes to Spotlight

To attribute writes to a specific process you need fs_usage:

sudo fs_usage -w -f filesys mds_stores | head -30

This streams every filesystem call mds_stores makes. On a misbehaving system you will see it open and rewrite the same index files over and over — ~/.Spotlight-V100/Store-V2/<uuid>/store.db, live.0.shadow, and a handful of journal files. On a healthy system you will see occasional bursts, then long quiet stretches.

If fs_usage confirms the suspicion, the next question is which path it is indexing. Add the -w and -e flags and tail the live output while you watch Activity Monitor; or run:

sudo log stream --predicate 'process == "mds_stores"' --info

The log lines usually name the volume or directory being touched. Most users discover one of three culprits: a Time Machine destination, a developer tree with a sprawling node_modules, or an external drive that is intermittently connected.

What Apple changed

Apple has not published a root-cause writeup of the Sequoia bug, but Michael Tsai's running notes from July 2025 collected enough evidence to outline the pattern: a state-tracking bug in the indexer caused it to repeatedly re-import files it had already imported, and to rewrite its store files on every pass. Tahoe 26 ships a different scheduler and the worst symptoms are rarer, but the same code path is still there — and any path-level configuration mistake on your machine can re-create the failure mode locally.

What to do today

The mitigation list is short and boring on purpose:

Exclude busy paths. System Settings → Spotlight → Privacy, add anywhere node_modules, build artifacts, large media libraries, or Time Machine backups live. macOS pauses indexing on those paths immediately.
Rebuild the index once. sudo mdutil -E / erases the existing store and triggers a fresh build. Counterintuitively, this often reduces total writes because the new build does not carry the broken state forward.
Watch the counters for a week. Re-check Data Units Written after seven days. If your daily rate has dropped back into the tens of GB, you are done. If it has not, see our mdworker high-CPU fix guide for deeper steps.
Decouple the launcher hotkey. If you also use ⌘Space as your daily launcher, this is a good moment to detach it. A local-only launcher like CmdSpace keeps working even while Spotlight is rebuilding, and CmdSpace's own index is bounded and tiny (a single Rust-backed inverted index file, typically under a few hundred MB).

Should you worry about long-term damage

Almost certainly not. Even at the worst Sequoia rates, the SSDs people actually run their Macs on are unlikely to die before the rest of the laptop ages out. The real cost was thermal — fans spinning more, batteries draining faster on the road, and uncomfortable lap temperatures. If your numbers look normal after the steps above, you can stop worrying and go back to making things.

The deeper lesson is more about trust than hardware. macOS' background daemons are mostly invisible until they are not, and when they go wrong the failure mode is gradual. A launcher that runs entirely in user space, with a local-only index you can delete and rebuild on demand, removes one whole class of "did my OS just do something to my hardware" anxiety from the stack.