The "Optimize Mac Storage" Trap: Why Apple Photos Still Consumes Your SSD (And How to Actually Fix It)

If your Mac has a 256 GB or 512 GB SSD, you have likely encountered the persistent macOS warning: "Your disk is almost full." You navigate to System Settings > General > Storage, look at the colorful breakdown, and discover that Apple Photos is eating 80 GB, 140 GB, or even 220 GB of your internal drive.

Naturally, you enable Apple's recommended fix: "Optimize Mac Storage" under iCloud Photos settings. Apple promises this will keep low-resolution versions on your device while storing the originals in iCloud, freeing up space when disk capacity runs low.

Weeks later, your disk is still completely full. Your Mac begins lagging, kernel tasks spike, and applications like Xcode, Final Cut Pro, or system updates refuse to install with error codes stating "There is not enough disk space." Here is the technical breakdown of why this happens, how APFS purgeable storage really works, and how to safely reclaim your hardware.

1. What is Inside ~/Pictures/Photos Library.photoslibrary?

In macOS, your Photos library is not a single file; it is an APFS package directory. If you right-click it in Finder and choose Show Package Contents, you will see several mission-critical directories:

• database/Photos.sqlite: The core relational database holding metadata, EXIF tags, albums, face recognition vector embeddings, and machine-learning scene classifications. In a 60,000-photo library, this database and its companion WAL journals can easily exceed 6 GB to 12 GB alone.
• resources/derivatives/: Previews generated by macOS for fast scrolling in the UI (micro-thumbnails, 256px squares, and full-screen 1080p transcodes). Even with "Optimize Mac Storage" turned on, these derivatives never leave your Mac.
• resources/cpl/: Cloud Photo Library transaction records, synchronization state tables, and upload/download staging queues used by the cloudphotod system daemon.
• originals/: The master, uncompressed RAW, HEIC, JPEG, and QuickTime files captured by your camera sensor.

2. The APFS "Purgeable Space" Mechanism

When you turn on "Optimize Mac Storage", macOS does not immediately delete your local originals. Instead, the APFS filesystem marks their inodes with the SF_DATALESS flag or registers their storage blocks as Purgeable.

Finder and Storage Settings helpfully report this space as available (e.g., "110 GB Available (65 GB Purgeable)"). But here is the critical flaw: macOS only purges these files when the internal SSD reaches acute starvation levels (often under 8-10% physical free blocks).

Third-party installers, virtual machines, local AI models (such as Ollama or LM Studio), and development build tools do not allocate space through high-level Cocoa APIs; they make POSIX statvfs() system calls. They inspect physical free blocks, see that the disk is full, and fail immediately. Meanwhile, your Mac throttles swap memory (/private/var/vm/swapfile*), resulting in noticeable system beachballs.

3. The Two-Way Sync Trap: iCloud is Not a Backup

Many users attempt to solve this by manually opening Apple Photos on their Mac, selecting 50 GB of heavy 4K videos, and hitting Delete. Within seconds, the cloudphotod daemon synchronizes that deletion across Apple servers:

If you try to disable iCloud Photos on your Mac, macOS presents an impossible ultimatum: "Do you want to download a copy of your iCloud Photos to this Mac?" If your SSD is already at 95% capacity, you physically cannot download them. If you select "Remove from Mac", all optimized photos vanish from your local machine, leaving you dependent on web browser downloads.

4. The Solution: Decoupled Unidirectional Relay

To achieve true storage freedom without losing a single memory, you must decouple your storage from Apple's bidirectional sync engine using a verified unidirectional pipeline:

5. Terminal Diagnostic: Checking Real vs Purgeable Space

To inspect the exact physical state of your Mac's storage without Finder's optimistic rounding, open Terminal and run:

# Check physical container free capacity vs purgeable reservation
$ diskutil apfs list

# Inspect local Time Machine APFS snapshots holding blocks
$ tmutil listlocalsnapshots /

Notice the difference between physical free containers and APFS snapshot allocations. Clearing out raw masters through PhotoRelay frees the actual container storage blocks permanently.

Method Comparison: iCloud vs External Hard Drive vs PhotoRelay

Frequently Asked Questions

Why does System Settings show 50 GB of Photos even after turning on Optimize Storage?

Because "Optimize Storage" leaves full-resolution database index files (Photos.sqlite) and UI image derivatives (resources/derivatives/) intact on disk. Furthermore, original media files are only marked as purgeable and remain on physical disk until macOS runs out of space.

If I delete photos from my Mac after PhotoRelay uploads them, do they disappear from Google Photos?

No. PhotoRelay operates on a strictly decoupled, unidirectional relay protocol. Once an item is confirmed in Google Photos, deleting the local file on your Mac has zero effect on your Google Photos cloud library.

What happens if my Wi-Fi drops while PhotoRelay is uploading?

PhotoRelay maintains an ACID-compliant on-device SQLite ledger. Every individual asset's state (Pending, Exported, Uploading, Confirmed) is tracked. If the connection interrupts, it safely resumes from the exact byte without duplicate uploads or partial deletions.