How much free space does an APFS disk need?

This has become one of the most popular questions put to me since the arrival of APFS, whether in specifying internal storage for a new Mac, or when managing external disks. The simple answer is that it depends, and here I try to explain some of the more significant things it depends on. To keep this as simple as possible, I consider only disks which will be formatted in APFS, and are primarily used with Big Sur or Monterey.

Are you going to boot macOS from it?

Since Catalina, macOS boot disks have had a formal structure which greatly affects free space. This is also different for the internal SSDs of M1 series Macs, which contain two additional hidden partitions/containers, which aren’t present in Intel Macs or external storage. Thankfully, those additional containers are small, well under 10 GB in total, so don’t need to be taken into account here.

There are now six volumes grouped together in the container from which your Mac boots macOS. As they’re volumes within the same container, they share the same free space. Thus, to work out how much free space that container (and the whole disk) needs, you need to consider how much could be required for each of those volumes, and add them together to give a total.

Preboot and Recovery are both relatively small, and should total well under 5 GB even during updating. The more recent Update volume is very small between updates, but is used for preparation and staging of macOS updates, when it could reach 15 GB or more. The System volume itself is just over 15 GB, and may require a bit more than that during updating. Together these volumes could require a maximum of around 40 GB at their peak.

The size of the VM volume depends entirely on how much virtual memory is required during use. If your Mac has ample physical memory, then it should remain less than 50 KB, but could grow to 20 GB or more if the software running needs much more memory than is available.

The volume that you’re most in control of, Data, stores a mixture of different data, which are reflected in the three different estimates of free disk space:

  • Free space is the difference between the total storage available on the disk, and that currently in use, and might come to 214 GB on a well-used 1 TB internal SSD.
  • Space available for important usage is likely to be significantly more, as it represents how much space could be made free when it’s essential. This should allow for the deletion of temporary files, volatile caches, and most snapshots other than the signed and sealed snapshot on the System volume, from which your Mac is booted. This space might be 268 GB.
  • Space available for opportunistic usage is the lowest of the three, and represents that readily available without removing anything. This might be as little as 203 GB.

The figure shown in the Finder should now be equal to the first of those, and the same as that shown in Disk Utility. Various utilities show the other two, for example my free Mints.

To estimate how much space your Data volume requires from the boot container, you’ll need to know how much is needed for regular files. To that, you should add an allowance for each of the following:

  • snapshots, if using a backup utility such as Time Machine, which routinely makes volume snapshots of all those volumes it’s backing up;
  • app temporary and cache files. These vary very widely, and no single figure can be given. You need to know the demands of your apps and your work using them;
  • macOS working files, such as those in the ~/Library/Trial folder. On occasion these can rise above 5 GB, but that should be very unusual;
  • system temporary and cache files, which should come to no more than 5 GB or so.

Your Mac’s likely free space requirement for the boot container thus comes to around (40 + 10 + VM + snapshots + caches) GB, plus ‘real’ free space.


Because snapshots will normally be deleted when free space is getting dangerously low, you don’t necessarily have to include them in your allowance. However, if your backup software makes them, it seems futile if they are then to be deleted quickly because the disk is running out of free space.


Working on the basis of a 24-hour retention policy, as fixed in Time Machine, to estimate the amount of space required to retain those snapshots, you need to know the file data turnover for each volume within the container during 24-hour periods. Remember that, even if you exclude almost every folder on a volume from Time Machine backup, if it backs up anything on that volume then a whole-volume snapshot will be made every hour.

This poses particular problems with very large apps and their installers, such as Xcode. In normal naïve use, you might copy Xcode’s compressed .xip archive to a folder on your Data or an external volume, decompress it, and move that app into an Applications folder. A snapshot made at the wrong time during that process could require more than 64 GB of disk space until it’s aged out of that volume’s snapshots.

If you don’t want to make allowance for such large snapshots, the simple alternative is to create another volume to be added to the backup exclusion list, so that no snapshots are made of it. Download the .xip archive onto that volume, decompress it there, and finally replace the old version with the new. That will still result in one snapshot containing the old version, but the archive and any intermediate copy won’t take up space in a snapshot.

Putting it together

Assuming that snapshots will never exceed 5 GB in any 24-hour period, and VM and cache requirements are no larger, the total free space required now comes to around 60 GB for the Data volume in a boot container, or less than 10 GB in a normal storage container. Now you can add your own allowance to ensure that you’ve got headroom to use that disk, taking it perhaps to 100 GB for a boot disk, and 25 GB or more for others. If you’re really tight for space, when using a Mac with very little internal storage, or you’re squeezing multiple systems onto an external disk, you can get away with much less, but will be at risk of not being able to update macOS or install a new version of Xcode.

There are other benefits from sizing SSDs and hard disks considerably larger so as to maintain ample free space. One key factor which determines the working life of an SSD is the number of times its storage gets erased and re-written. Thus, a high write load on a small SSD will reach the maximum number of writes more quickly than the same write load on a larger SSD. For a hard disk, keeping the inner sectors free of data will result in faster read and write performance, while filling the disk will lead to slower access to its contents stored towards the centre of its platter.

So it depends…