• The problem. System Data jumped after macOS 27. Spotlight’s search index is counted in it without being named, in a folder even an app with Full Disk Access can’t read.
  • What we found. Spotlight rebuilt its index after the update, and its files reached 61.97 GB on one Mac. Turning indexing off gave back 44 GiB, about 47 GB, but search stopped finding our files and apps.
  • What we built. Mint 1.0.82 and later lists Spotlight’s index in Safe to clean under its own chip. It’s never ticked for you, and Delete turns indexing off and erases the index with one password.

If System Data jumped after you installed macOS 27, look at Spotlight's search index before you delete anything. The index can grow large while it rebuilds, the Storage pane counts it as System Data without naming it, and you can measure it from Terminal without changing a thing. The numbers below come from one Mac, and how big the index gets on yours depends on what's on it.

One line in the Storage pane

System Settings > General > Storage shows System Data as a single line you can't open. Swap, caches, backups and snapshots end up there too, and our System Data guide goes through them. Apple Intelligence's models, which macOS 27 also downloads, are counted under macOS instead, and we measured them on the same Mac. Spotlight keeps its index in a hidden folder called .Spotlight-V100 at the top of the data volume, and the folder belongs to the system. An app with Full Disk Access can't read inside it, and on this Mac sudo du from a Terminal without Full Disk Access was refused as well. So when System Data moves, nothing on screen tells you how much of the change is the index.

What happened after the update

macOS 27.0.1 finished installing at about 09:25 on September 29.

Before the update, macOS reported that it could free 68.15 GB of Spotlight data if it ran short of space. By 12:46 that day the figure was 3.90 GB. Over the same hours, the used space that Mint's scan couldn't trace to any folder it can read went from 85.57 GB to about 5 GB. We read that as the old index being thrown away during the update. No log entry says which process deleted it, or when.

Then Spotlight began building a new one. Apple's mdutil -L lists the files in the index folder; it needs the admin password and only reads. Adding up the lengths of the files it listed:

when            files   total length
Sep 29, 13:26     559        5.43 GB
Sep 30, 01:01     684       34.29 GB
Oct 1, 12:40      714       61.97 GB

Between 14:57 and 22:13 on September 29, a new segment file was written every 9 to 26 minutes, nearly all of them 512 MiB or 1 GiB long. Late on September 30 the index started over: in the October 1 listing, the oldest segment is from 23:51 that night. We don't know why it restarted. By 12:40 the next day a single file was 34.36 GB long, exactly 32 GiB.

Those round sizes are why we call these numbers lengths. A program can set a file's length before it writes the data, so a length can run ahead of the space the file takes on disk. We had no way to count the blocks, and the listing skips the index's Cache folder.

When free space dropped

On October 1 free space fell by more than 80 GB in under twelve hours, from 100.6 GB at 00:39 to 13 GB at 12:16. Spotlight's index was the biggest single piece. A virtual machine image and other work took the rest.

That day macOS was saying it could free 16.09 GB of Spotlight data, and the number hadn't moved, to the byte, in 22 hours of the index growing. It's what macOS offers to give back when it needs room. It doesn't measure the folder.

Taking it back, and what that cost

We turned indexing off for the data volume (mdutil -i off) and free space went up by 44 GiB, about 47 GB in the units the Storage pane uses. In the next 20 seconds we also erased the index (mdutil -X) and restarted chronod, a system process that was holding about 5 GB of deleted files. Free space rose another 4 GiB, and we can't split that between the two. We first counted all 4 GiB as the index's. A later test showed that restarting chronod gives back nearly everything it holds, so most of it was probably chronod's. Either way the index gave back at least 44 GiB, less than the listing's 61.97 GB, which fits the lengths running ahead of the data.

Apps kept working, but search stopped. With indexing off on the data volume, Spotlight found none of our files and none of the apps we'd installed: Mint, Raycast, Chrome and Claude each returned nothing. macOS's own apps, like Safari, still showed up, because the system volume keeps its own index. A search limited to one folder (mdfind -onlyin) still answered, because it walks that folder instead of asking the index.

When we turned indexing back on, a new index folder appeared within a minute, and for the first 16 minutes macOS put its size at 0 bytes.

Why this index got so big

On September 29, with the rebuild running, mdfind counted 173,080 indexed items in the folder that holds this Mac's code projects. 56% of them were in two folders of research data and exported datasets, tens of thousands of JSON, CSV and Parquet files. That shows the index had a lot to cover there. It doesn't show how many bytes of the index each folder costs, and we don't know of a tool that reports that. The count was still moving, too: five minutes later it was 173,081.

Check yours

Everything here only reads.

  1. Open System Settings > General > Storage, let it finish, and note System Data and your free space.
  2. In Terminal, run the first line below to see whether indexing is on for your data volume.
  3. Paste the next two lines together, since they're one command, to add up the index files. It asks for your password and changes nothing.
mdutil -s /System/Volumes/Data
sudo mdutil -L /System/Volumes/Data |
awk '/^-/{s+=$5} END{print s/1e9, "GB"}'

The total is file lengths, not exact disk use, and it leaves out the index's Cache folder. Run that command again an hour later. If the total keeps climbing and mds_stores is busy in Activity Monitor, Spotlight is still building. During the rebuild here, one sample caught it at 54.3% CPU.

Your options

Each one costs something.

  • Wait. Apple says indexing after an update can take hours or even days. If the total levels off and search works, you may not need to do anything.
  • Rebuild it. Apple's way: System Settings > Spotlight > Search Privacy, add the disk, wait a few seconds, then remove it. Spotlight indexes it again from scratch, so you trade one rebuild for another. We haven't measured whether the new index ends up smaller.
  • Leave out folders you never search. Add them to the same Search Privacy list and they stop appearing in results. Whether this keeps the index smaller is something we haven't measured yet. Apple warns that excluding folders can mean you aren't told about some app updates, and excluding the whole internal disk means you aren't told about any.
  • Turn indexing off. The first line below gives the space back and the second brings indexing back. While it's off, Spotlight can't find your files or the apps you installed.
sudo mdutil -i off /System/Volumes/Data
sudo mdutil -i on /System/Volumes/Data

Whichever you pick, don't delete files inside .Spotlight-V100 by hand. Use Apple's tools instead; its notes on Spotlight indexing and on excluding folders cover the settings.

Where Mint fits

Mint 1.0.82 and later, downloaded from our website, lists Spotlight's index in Safe to clean under a chip of its own. It shows the size macOS declares, which is a lower bound, and after a removal it reports what came back. It's never ticked for you, and Auto Care never runs it. Delete turns indexing off and then erases the index, with one password, and the same chip turns indexing back on.