RAM Disk on Mac: 11x Faster Reads, No Faster for git or tar

A RAM disk on a Mac is still easy to make: one hdiutil call and one diskutil call, no admin password. On the Mac mini M4 that runs this blog, it read a 1 GiB file 11 times faster than the internal SSD and finished a fully flushed 4 KB write 164 times faster. Then I used it for ordinary work. Extracting 2,871 files, git add on them and python3 -m compileall took the same time on the RAM disk as on the SSD, within 10 percent either way.

The memory side had more surprises than the speed side. A RAM disk smaller than 4 GiB took all of its memory the moment I attached it, and one of 4 GiB or more took almost none. Deleting files never gave memory back. And the warning in man hdiutil that RAM disks use wired memory describes a mode this macOS no longer supports.

How to make a RAM disk on Mac

The size goes in 512-byte sectors, so multiply the number of MiB by 2048. This makes a 4 GiB APFS RAM disk called RAMDisk and mounts it at /Volumes/RAMDisk:

$ diskutil erasevolume APFS RAMDisk $(hdiutil attach -nobrowse -nomount ram://8388608)
Started erase on disk4
...
Finished erase on disk4

$ df -h /Volumes/RAMDisk
Filesystem      Size    Used   Avail Capacity iused ifree %iused  Mounted on
/dev/disk5s1   4.0Gi    24Ki   4.0Gi     1%       2   42M    0%   /Volumes/RAMDisk

# when you're done (this is what frees the memory)
$ hdiutil detach /Volumes/RAMDisk
"disk4" ejected.

Leave the $(...) unquoted. hdiutil attach prints the device name followed by tabs and spaces, and quoting it passes the padding to diskutil. -nobrowse only hides the volume from Finder's sidebar. Swap APFS for HFS+ if you want the faster of the two for flushes (below).

Older guides say APFS doesn't work here. The accepted answer on Create an APFS RAM disk (2017, High Sierra) builds a JHFS+ volume and converts it. On macOS 26.4.1, diskutil erasevolume APFS on a raw RAM device worked first time at every size I tried, in about 1.9 seconds. Most of the time to create one is the format: the hdiutil attach step took 0.4 seconds.

RAM disk vs SSD: the benchmark

I made a 2 GiB APFS and a 2 GiB HFS+ RAM disk and ran the same Python script three times against each and against a folder on the internal SSD. Sequential tests used F_NOCACHE so the file cache didn't answer for the drive. Each figure below is the median of three runs.

Test	Internal SSD	APFS RAM disk	HFS+ RAM disk
1 GiB write, uncached	4,722 MB/s	7,357 MB/s	9,557 MB/s
1 GiB read, uncached	1,079 MB/s	11,936 MB/s	11,904 MB/s
4 KB write + fsync	45 µs	17 µs	12 µs
4 KB write + F_FULLFSYNC	3,890 µs	106 µs	24 µs
SQLite insert, default settings	308 µs	137 µs	125 µs
SQLite insert, PRAGMA fullfsync=ON	12,699 µs	359 µs	172 µs
untar 2,871 files (69 MB)	0.750 s	0.690 s	0.729 s
create 20,000 files of 1 KB	0.873 s	0.850 s	0.762 s
delete those 20,000 files	0.707 s	0.916 s	0.466 s

Then I ran the kind of work people move to a RAM disk: extract the Python 3.14 standard library from a tar, git init and git add -A the result, commit, byte-compile it with compileall, and run 200 inserts through the sqlite3 command-line tool. Three runs each, a 4 GiB APFS RAM disk against the SSD:

Step	Internal SSD	APFS RAM disk
tar -xf	0.771 s	0.698 s
git add -A	1.225 s	1.190 s
git commit	0.099 s	0.104 s
python3 -m compileall	2.613 s	2.638 s
200 × sqlite3 CLI insert	0.522 s	0.503 s

The best case was the tar at 10 percent faster. The commit and the compile were a hair slower on the RAM disk, which is noise.

Why the big numbers don't show up in real work

Three things close the gap.

First, macOS already keeps recently used files in RAM. The uncached-read row is the one comparison where the SSD had to go to flash for every block, and that's the row with the 11x. A build that reads the same headers over and over gets them from the file cache on either volume.

Second, a plain fsync on macOS doesn't wait for the flash. Apple's fsync(2) man page says so, and points programs that need their data on permanent storage to the F_FULLFSYNC fcntl. That's why the SSD's plain fsync took 45 µs and the full flush 3,890 µs. SQLite by default uses plain fsync on macOS, and only does the full flush if you turn on PRAGMA fullfsync. With the default, the RAM disk was 2.2 to 2.5 times faster per insert. The 35x to 74x only appears when a program asks for the real flush. So a test suite that hammers a database with full durability turned on is the workload I found where a RAM disk pays for itself.

Third, the metadata path is CPU work. Creating, listing and deleting files goes through the same file system code either way, so untar and the 20,000-file test barely moved. APFS on a RAM disk was actually slower than the SSD at deleting 20,000 files, 0.916 against 0.707 seconds. HFS+ was the faster RAM disk format in every row except uncached reads, where they tied, and the untar, where APFS was 0.04 seconds ahead.

A 2014 Ask Different answer on whether a RAM disk improves OS X performance puts RAM at "between 10 to 1000 times" the SSD. On this M4 the range was 0.8x to 164x, and the everyday tasks sat at the bottom of it.

Where the memory goes

A RAM disk isn't a kernel feature here. Each one is served by its own diskimages-helper process, and the disk's contents are that process's heap. hdiutil info shows the process ID next to image-path : ram://..., and footprint on that process showed the data as dirty MALLOC_LARGE memory. Activity Monitor puts the same number in the helper's Memory column.

The size I asked for decided when that memory was taken. I attached RAM disks without formatting them and read the helper's resident size straight away:

Requested size	Helper memory right after attach
512 MiB	533 MB
2 GiB	2,106 MB
3 GiB	3,155 MB
4,095 MiB	4,202 MB
4,096 MiB (4 GiB)	9 MB
8 GiB and 16 GiB	9 MB

Under 4 GiB, the whole disk is allocated up front. At exactly 4 GiB and above, memory is taken as blocks are written. One MiB of difference in the request moved 4.2 GB of memory. So if you're making a scratch disk on a 16 GB Mac, a 4 GiB disk you only half fill costs less than a 3 GiB one. The lazy mode has no ceiling either: a 32 GiB RAM disk attached on this 16 GB machine without a warning. I didn't fill it, since past 16 GB the only place for the data is swap.

Deleting files doesn't hand memory back. On a 4 GiB disk the helper went from 13 MB to 1,062 MB when I wrote a 1 GiB file, stayed at 1,062 MB after rm and 15 seconds of waiting, and stayed there when I wrote a second 1 GiB file. The file system reuses the freed blocks, so memory use is the high-water mark of what was ever on the disk, not what's on it now. HFS+ behaved the same way. An Ask Different question from 2023 describes exactly this; its only answer blames the volume's Trash, but I deleted with rm, which never touches the Trash, and nothing came back. The only release I found is hdiutil detach.

The memory isn't wired, either. man hdiutil warns that "ram:// images use wired memory when attached in-kernel". Writing 1.5 GB to a RAM disk moved the wired count in vm_stat by 22 pages, and the in-kernel mode the warning refers to is gone: hdiutil attach -kernel ram://1048576 failed with "Function not implemented". Because the data is ordinary process memory, macOS can compress or swap it like any app's heap. Once, a 2 GiB helper whose whole disk was allocated showed only 1.38 GB resident while the compressor was holding about 2.3 GB, which is what compression or paging looks like. I didn't force memory pressure to prove a round trip to swap. If your Mac is already swapping, a RAM disk adds to the problem rather than avoiding the SSD. vm_stat swap usage on Mac covers how to read those counters.

tmpfs exists on macOS, but it needs root

People searching for tmpfs on Mac usually land on the hdiutil recipe, but macOS has had a real one since macOS 11. /sbin/mount_tmpfs is on this machine, and its man page says it "first appeared in macOS 11". Run as a normal user it failed:

$ mkdir /tmp/t && mount_tmpfs -s 64M /tmp/t
mount_tmpfs: Unsuccessful mount: Operation not permitted

The open-source TmpDisk app (507 stars, v2.3.3 released 2026-09-20) offers both: its code builds the hdiutil attach -nomount ram:// command for APFS and HFS+ disks and calls mount_tmpfs for TMPFS, and its README says TMPFS needs admin privileges. I couldn't run sudo in this session, so I have no tmpfs numbers, and I don't know whether tmpfs releases memory on delete the way Linux tmpfs does.

When a RAM disk on Mac is worth it

• Worth it: anything that calls F_FULLFSYNC a lot, such as test suites against SQLite with fullfsync on or other databases set for strict durability. Also large files you'll read once and throw away, where the cache can't help.
• Not worth it: unpacking archives, git checkouts, Python bytecode, most build directories. They ran at SSD speed here.
• If you make one: pick HFS+ unless you need APFS features, use 4 GiB or more so memory is taken only as you write, and detach it when you're done, because deleting files frees nothing.
• SSD wear isn't a strong reason on its own. On a machine that swaps, the RAM disk can push other memory onto the SSD instead.

Everything is lost on restart, and a 2011 Ask Different thread reports a RAM disk unmounting after sleep on a laptop. This Mac mini doesn't sleep, so I didn't test that. For disposable files that should survive a reboot, the plain-disk options in macOS /tmp cleanup are simpler. Other ram:// details, like the sparse and shadow image types, are in the hdiutil post, and if the real question is how much memory a small always-on Mac needs, Mac mini 16GB vs 24GB has the numbers from this one.

FAQ

How do I create a RAM disk on a Mac?

Run diskutil erasevolume APFS RAMDisk $(hdiutil attach -nobrowse -nomount ram://8388608) in Terminal. The number is the size in 512-byte sectors, so MiB times 2048; 8388608 is 4 GiB. It needs no admin password and mounts at /Volumes/RAMDisk. Use HFS+ instead of APFS for faster flushes. Run hdiutil detach /Volumes/RAMDisk to remove it and free the memory. Everything on it is lost at restart.

Is a RAM disk faster than the SSD on Apple silicon?

For some operations, by a lot. On a Mac mini M4 a RAM disk read a 1 GiB uncached file 11 times faster than the internal SSD and finished a 4 KB write with F_FULLFSYNC up to 164 times faster. But extracting 2,871 files, git add and python compileall ran within 10 percent of the SSD, because macOS already caches files in memory and plain fsync doesn't wait for the flash.

Why doesn't deleting files on a Mac RAM disk free memory?

The RAM disk is the heap of a diskimages-helper process, and the file system doesn't tell it when blocks are freed. In a test on macOS 26.4.1, writing a 1 GiB file raised the helper to 1,062 MB and deleting it with rm left it there. Freed blocks are reused for new files, so usage stays at the high-water mark. Only hdiutil detach releases the memory.

Method: all tests ran on 2026-10-10 between 12:00 and 12:40 KST on a Mac mini M4 (Mac16,10, 16 GB, internal SSD, macOS 26.4.1 build 25E253) as a normal user over SSH, with Python 3.14.7 and git 2.54.0. RAM disks were made with hdiutil attach -nomount ram:// and formatted with diskutil erasevolume. Throughput and latency come from a Python script using F_NOCACHE, fsync and fcntl F_FULLFSYNC (500 writes and 500 SQLite autocommit inserts per run), three runs per volume, medians shown; the tar was the Homebrew Python 3.14 standard library. Memory figures are the diskimages-helper resident size from ps, cross-checked with footprint, and vm_stat for wired pages. Ask Different questions and answers were read through the Stack Exchange API, and TmpDisk's source through the GitHub API. I didn't test tmpfs (needs root), Intel Macs, external drives, other macOS versions, sleep, or what happens when a RAM disk is filled past physical memory. All RAM disks were detached afterwards.