The Postgres data folder's size on a Mac is the size of your databases plus a few files PostgreSQL manages itself. Postgres.app keeps it in ~/, in a folder such as var-17, and Homebrew in /, in one such as postgresql@17.
Get Info in Finder shows its size. Most of it is your data. What grows without you adding anything is PostgreSQL's write-ahead log, its server log, and whole data folders left behind by major upgrades. MySQL, Redis, MongoDB and SQLite have their own: binary logs, append-only files, server logs and -wal files.
None of it is a cache. Remove a database you no longer need with the database's own tools, so its files go cleanly; remove a whole data folder only when you've finished with that server, with the server stopped, and after making a dump if there's anything in it you might want.
This post goes through where each of these databases keeps its files on a Mac, which parts grow by themselves, and how each database's own tools give space back.
Where local databases keep their data on a Mac
Each database server keeps everything in one folder, its data directory. Where that is depends on how you installed it, not on the database.
| Database | Installed with | Data folder | Logs |
|---|---|---|---|
| PostgreSQL | Postgres.app | ~/Library/Application Support/Postgres/var-17 | postgres-server.log in the data folder |
| PostgreSQL | Homebrew | /opt/homebrew/var/postgresql@17 | /opt/homebrew/var/log/postgresql@17.log |
| MySQL or MariaDB | Homebrew | /opt/homebrew/var/mysql | A .err file in the data folder |
| MySQL | MySQL's installer | /usr/local/mysql/data | mysqld.local.err in the data folder |
| Redis | Homebrew | /opt/homebrew/var/db/redis | /opt/homebrew/var/log/redis.log |
| MongoDB | MongoDB's Homebrew tap | /opt/homebrew/var/mongodb | /opt/homebrew/var/log/mongodb/mongo.log |
| SQLite | Your app or project | Wherever the app puts its .sqlite or .db file | None of its own |
On an Intel Mac, Homebrew's folders are under / instead of /. The version numbers are examples: each major version gets a folder of its own.
How do you check a data folder's size?
Finder shows it, as long as you can open the folder.
- In Finder, choose Go › Go to Folder, or press Shift-Command-G.
- Type the folder that holds the data, such as
/oropt/ homebrew/ var ~/, and press Return.Library/ Application Support/ Postgres - Select a data folder and choose File › Get Info. The size appears under General once Finder has counted it.
MySQL's installer runs its server under its own account, so Finder may not be allowed to open / or count it.
Where do databases show up in Storage settings?
Mostly in System Data. Storage settings, in System Settings › General › Storage, has no category for databases, so data folders in your Library and Homebrew's folders count as System Data, along with everything else it can't name.
Two exceptions: a SQLite file inside one of your projects is counted with your documents, and a database running in Docker lives inside Docker's own disk file, which Storage settings also counts as System Data.
Are any of these folders caches?
No. Almost everything in a data folder is the database: your tables, the logs it needs to recover after a crash, and its settings. The server reads it when it starts, and some of it is written every second it runs. A server's text log, where it's kept there, is the one exception.
That's why a database is never something to clear in bulk. The space comes back either through the database's own tools, or by deciding a whole database, or a whole server, is no longer needed.
Postgres data folder size on a Mac: what's inside
A PostgreSQL data folder, which PostgreSQL's documentation calls the cluster's data directory, has a fixed layout. Knowing what each part holds explains most surprises about its size.
| Folder or file | What it holds |
|---|---|
base | One folder per database, named by a number rather than the database's name |
pg_wal | The write-ahead log: recent changes, kept for crash recovery |
global | Tables shared by the whole server, such as the list of databases |
pg_xact | Records of which transactions committed |
postmaster.pid | A lock file that exists only while the server runs |
Most of the size is usually in base. PostgreSQL's documentation explains that each database's folder there is named after its internal ID, so Finder can show you which database is large, but not which one it is by name.
Why is pg_wal so large?
PostgreSQL writes every change to the write-ahead log before it changes the tables, so it can recover after a crash. At each checkpoint, it removes or recycles the log files it no longer needs.
By default it aims to keep the log under 1 GB, its max_wal_size setting, and keeps at least 80 MB ready for reuse. The documentation stresses that 1 GB is never a hard limit. A burst of changes, such as loading a large dump, can push it past that for a while.
When does pg_wal keep growing?
When something tells PostgreSQL to keep old log files. Its documentation names the usual causes:
- A replication slot nobody reads. A slot made by a replica, or by a tool that streams changes, keeps every log file that reader hasn't received.
- Archiving that fails. If log archiving is turned on and keeps failing, old files pile up until it works again.
- A setting that keeps extra log. A size set to keep for replicas is kept on top of everything else.
On a Mac used for development, replication and archiving are usually off, so a slot left by a tool you tried is the one to look for. Remove the slot with PostgreSQL's own tools, and PostgreSQL removes the files at its next checkpoint.
Can you delete files in pg_wal?
No. The write-ahead log is part of the database, not a record of it: PostgreSQL needs those files to recover after a crash, and removes the ones it doesn't need by itself. Deleting them by hand can leave the server unable to start, or the data inconsistent.
The same goes for every other folder in the data folder. If pg_wal is large, find the reason above and fix that.
Why doesn't deleting rows shrink the folder?
Because PostgreSQL keeps the space for reuse. Its documentation says a standard vacuum, which runs automatically, marks the space of deleted rows as free for future rows, but doesn't return it to the Mac, except for empty pages at the very end of a table.
A full vacuum rewrites a table without the dead space and returns it to the Mac. It locks the table while it works and needs room for the new copy until it's done. In pgAdmin, its Maintenance dialog runs a vacuum on a database or table, with a FULL switch for the full kind.
Dropping a database you no longer need
Old test databases and copies of production data are often the bulk of a developer's data folder. Dropping a database removes its folder in base straight away; PostgreSQL's documentation says it can't be undone.
Use a database app such as pgAdmin, Postico or TablePlus to see each database's name and drop the ones you're sure about. Never remove numbered folders in base in Finder: the server still lists those databases, and it can't open them.
Old PostgreSQL versions: the folders upgrades leave behind
A new major version of PostgreSQL can't read an older version's data folder directly, so each major version gets a new folder. The old one stays, with every database in it, until you remove it.
Postgres.app's var folders
Postgres.app's documentation gives its default data folder as ~/, in a folder named var- and the major version. It can run several servers at once, each with its own folder, and lists them in its sidebar.
To move to a new version, its documentation describes copying your data across with PostgreSQL's tools, then, once you've tested that everything works, removing the old data from that folder. Until you do, the old version's folder keeps its full size.
Homebrew's postgresql folders
Homebrew names PostgreSQL's formulae by major version, such as postgresql@16 and postgresql@17, and gives each its own data folder in /. Older installations used a folder called postgres there, which Homebrew's notes for postgresql@14 suggest moving.
Uninstalling a formula with Homebrew removes the server, never its data folder. The post on Homebrew cleanup explains why data in / outlives the software that made it.
How do you tell whether an old data folder still matters?
Look at three things in Finder, in List view with the Date Modified column:
- Is there a
postmaster.pidfile inside? PostgreSQL's documentation says the file exists only while the server runs. If it's there, the server is probably running; stop it before anything else. - When did files in
baselast change? A folder untouched since you upgraded is likely a leftover. - Did your data make it across? Open the new server in a database app and check the databases you care about are there.
Before you remove a data folder
Stop the server, in Postgres.app or with Homebrew's services. Then, if anything in it might matter, make a dump with PostgreSQL's tools or a database app, and keep the file somewhere other than the folder you're removing.
Then move the whole data folder to the Trash in Finder, never part of it. Keep the Trash until you've confirmed the new server has everything; a data folder in the Trash can still be put back.
| Situation | Where the old data is | What to do |
|---|---|---|
| Upgraded Postgres.app to a new major version | ~/Library/Application Support/Postgres/var-16 | Check the new server, then move the old folder to the Trash |
Moved from postgresql@16 to @17 with Homebrew | /opt/homebrew/var/postgresql@16 | Check, stop the old service, uninstall the old formula, then move the folder |
| An old Homebrew install before versioned names | /opt/homebrew/var/postgres | Check whether anything uses it; dump it if unsure |
| Stopped using Postgres.app entirely | ~/Library/Application Support/Postgres | Its uninstall steps make removing data optional: dump first |
MySQL and MariaDB: binary logs and tablespaces
MySQL keeps every database as a folder inside its data folder, with a file per table. Next to them are files MySQL manages itself, and two of them explain most unexpected growth.
What are the binlog files?
Binary logs, a record of every change, used for replication and for recovering to a point in time. MySQL's manual says binary logging is on by default, and the files sit in the data folder, named binlog with a number that grows each time a new file starts.
A new file starts when the current one reaches 1 GB, and when the server restarts. By default, MySQL removes binary logs once they're 30 days old, but only when it starts or moves to a new log file, so a server that runs for weeks can keep more.
Can you delete binary logs?
MySQL's manual says you can remove the files by hand, but that it's better to use its own purge statement, which also updates the index file that lists them. If MySQL replicates to another server, keep the logs until no replica needs them.
On a Mac used only for development, nothing else usually reads them. MySQL's configuration file can shorten how long they're kept, or turn binary logging off, which its manual documents as a startup option.
Why doesn't dropping a table free space?
It depends where the table lives. MySQL's manual says tables are created in their own files by default, and dropping or truncating one of those returns its space to the Mac straight away.
Tables in the shared system tablespace, the file called ibdata1, are different. Space freed there stays inside the file for MySQL to reuse, and the file doesn't shrink. Old installations, and ones with file-per-table turned off, are where a large ibdata1 comes from.
What is ibtmp1?
MySQL's temporary tablespace, for temporary tables it makes while running queries. It starts at a little over 12 MB and grows as needed. MySQL's manual says it's removed at a normal shutdown and made again at startup, so restarting the server is how you reclaim its space.
MySQL's preference pane
MySQL's installer adds a preference pane of its own, which its manual still describes under System Preferences. It can start and stop the server and uninstall MySQL.
It also has an Initialize Database button, which the manual says recreates the data folder. That replaces every database you have with an empty one. It isn't a way to free space unless that's exactly what you want.
MariaDB and Homebrew
Homebrew's MySQL and MariaDB both use /. If you've switched from one to the other, the folder may hold data the other made, so check before treating it as either one's leftovers.
Apps that bundle their own MySQL, such as tools for running WordPress sites locally, keep separate data folders with their own settings. Manage those through the app.
Redis and Valkey: the dump file is the data
Redis keeps its data in memory and saves it to disk so it survives a restart. On disk, that's one or two kinds of file in its working folder.
Where does Homebrew's Redis keep its files?
Homebrew's Redis uses / as its working folder, writes its log to /, and reads its settings from /. Homebrew's Valkey, a fork of Redis, has the same layout under its own name: / and valkey.log.
dump.rdb and the append-only file
By default, Redis saves snapshots of everything to a file called dump.rdb, replacing it each time. Its documentation calls this compact and suited to backups. The size of dump.rdb follows the size of your data.
If the append-only file is turned on, Redis also logs every change. It rewrites that log automatically when it gets too big, keeping only what's needed to rebuild the current data. Since Redis 7, the log is several files in a folder of their own, tracked by a manifest.
Can you delete dump.rdb?
Only if you don't need what's in Redis. With the server stopped, removing the file means Redis starts empty. With the server running, Redis just writes a new one from memory at its next save, so nothing is freed.
On a development Mac, Redis often holds caches, sessions and job queues, which can go. To empty it or remove keys, use Redis's own tools, such as Redis Insight, its desktop app, and the file shrinks at the next save.
Is it safe to copy dump.rdb?
Yes. Redis's documentation says copying the file is safe while the server runs, because Redis writes each new snapshot under a temporary name and swaps it in only when it's complete. That makes it an easy backup before emptying anything.
MongoDB: data files and a log that keeps growing
MongoDB, installed with its own Homebrew tap, keeps data in / and writes its log to /. The tap's settings tell MongoDB to add to that log rather than replace it.
Why doesn't deleting documents shrink MongoDB's files?
MongoDB keeps freed space inside its files for reuse, much like PostgreSQL. Its compact command attempts to release unneeded space to the Mac. The documentation adds that how much it frees depends on where the free blocks are, and that it may need extra disk space to run.
Dropping a collection or a database you no longer need frees its files outright. MongoDB Compass, MongoDB's desktop app, can drop both.
What about the log?
The log grows with every start and every message, and the tap's settings never replace it. Stop the server, move mongo.log to the Trash, and MongoDB starts a new one when it next starts. Do the same with other servers' logs in /.
The data folder itself is the database. Leave everything in it, including the files whose names start with WiredTiger, to MongoDB.
SQLite: database files everywhere
SQLite isn't a server: it's a database in a single file, which an app opens directly. That makes SQLite files common on any Mac, and most of them belong to apps.
Where do SQLite files live?
Inside apps' own folders, mostly: ~/, ~/ and similar places, where apps keep their libraries, histories and settings. Those are the apps' data; manage them in the apps.
The ones that are yours are in your projects. Rails apps keep SQLite databases in the project's storage folder by default, Django creates db.sqlite3 at the top of a project, and test suites often leave copies behind.
What are the -wal and -shm files?
A database in SQLite's write-ahead log mode has two companions: a file ending in -wal, holding recent changes, and one ending in -shm, an index to it. SQLite's documentation says both are usually deleted when the last connection to the database closes.
While the database is open, SQLite moves changes from the -wal file into the database at checkpoints, by default once it reaches 1,000 pages. A checkpoint doesn't shrink the -wal file unless a limit is set. If readers keep the database open constantly, checkpoints can't finish and the file can grow without bound.
Can you delete a -wal file?
No. SQLite's documentation says the -wal file is part of the database's state: separated from it, committed changes can be lost or the database corrupted. The only safe way to remove it is to open the database and close it again, which is what an app normally does when it quits.
When you copy or move a SQLite database, move the -wal and -shm files with it, or quit the app first so they're gone.
How do you shrink a SQLite file?
SQLite leaves deleted data's space as free pages inside the file. Its vacuum command rebuilds the database without them, which can make the file much smaller. The documentation warns that it can need free space of up to twice the database's size while it works.
In DB Browser for SQLite, a free app, choose Tools › Compact Database. Work on a database no app has open, and only on your own databases, never an app's.
Databases in Docker and bundled apps
Many developers run databases in containers instead of installing them. The data is just as real; it's only harder to see.
Where does a database in Docker keep its data?
Usually in a volume, storage Docker keeps separately so it survives when the container is removed. Docker Desktop keeps volumes inside its single disk file, the Docker Desktop disk image (Docker.raw), so they never show up as folders in Finder.
Docker's documentation says plainly that deleting a volume deletes the volume and all its data, and its button for it says Delete forever. Remove volumes in Docker Desktop's Volumes view only when you're sure. The post on Docker Desktop disk space covers what else is inside that file.
Why doesn't Docker's disk file shrink when you delete a database?
Deleting rows inside a containerized database frees space inside the database, which keeps it for reuse, just as it would on your Mac. So Docker's disk file has nothing to give back. Dropping the database, or removing its volume, is what frees space Docker can return.
Apps that run a database for you
Some apps bundle a database server: local WordPress tools, Mac apps for running PHP and Laravel sites, and database apps that start servers on demand. Each keeps data in its own folder, usually in ~/.
Remove those databases in the app that made them. Its uninstall steps, if it has any, say whether data goes with it.
What grows by itself, and how each database reclaims it
Every database here keeps files it manages on its own, with defaults that keep them in bounds. These are the limits each project documents.
- PostgreSQL write-ahead log target1,024 MB
- MySQL binary log file, before a new one1,024 MB
- PostgreSQL log kept for reuse80 MB
- MySQL temporary tablespace at start12 MB
- SQLite -wal file at checkpoint3.9 MB
Defaults from PostgreSQL 18, MySQL 8.4 and SQLite's documentation, not measurements. PostgreSQL's target is soft, MySQL keeps binary logs for 30 days, and SQLite's figure is 1,000 pages of 4,096 bytes.
These are starting points, not ceilings. Several MySQL binary logs can exist at once, PostgreSQL can pass its target, and both Redis's and MongoDB's files follow the size of your data.
| What grows | Database | How it comes back |
|---|---|---|
pg_wal | PostgreSQL | Automatic at checkpoints; remove stale replication slots |
| Dead rows in tables | PostgreSQL | Automatic vacuum for reuse; a full vacuum returns it |
| Binary logs | MySQL | Automatic after 30 days; MySQL's purge statement |
ibtmp1 | MySQL | Restart the server |
| Append-only file | Redis | Automatic rewrite |
| Freed space in collections | MongoDB | Compact, or drop the collection |
-wal file | SQLite | Checkpoint and close; vacuum for free pages |
| Server logs | PostgreSQL, MySQL, Redis, MongoDB | Stop the server, move the log to the Trash |
Dump files you made yourself
Dumps, exports and copies made before an upgrade are ordinary files: .sql, .dump, .rdb or archives of them. They often end up in Downloads or in project folders and stay long after they've done their job.
They may also be the only copy of something. Open or check each one before it goes. The post on finding large files shows how to search Finder by size and kind.
Before you remove any database
Every way of freeing space in this post either removes data or rewrites it. A few minutes of checking first is cheaper than restoring a database you needed.
Questions to answer first
- Which server is it, and is it running? Stop it before touching its folder, in its app or with Homebrew's services.
- Does a project still point at it? Look at the project's settings, such as
config/database.ymlin a Rails app,settings.pyin a Django project, or aDATABASE_URLline in an environment file. - Is there a copy? If the data came from somewhere else, such as a shared test dump, you may be able to get it again. If you made it here, a dump is the only copy.
- Are you removing one database or a whole server? Dropping a database in a database app is narrower than moving a data folder, and leaves the server working.
What each action costs
| Action | What you lose | Can you undo it? |
|---|---|---|
| Move a stopped server's data folder to the Trash | Every database in it | Yes, until you empty the Trash |
| Drop a database or collection in a database app | That database or collection | No |
| Purge MySQL's binary logs | Recovery to points before them | No |
| Run a full vacuum, compact or SQLite's vacuum | Nothing but the free space | Nothing to undo |
Restart MySQL to shrink ibtmp1 | Nothing | Nothing to undo |
| Remove a volume in Docker Desktop | The database in it | No |
The Trash is the only step here with a way back, which is one more reason to remove a whole stopped server's folder in Finder rather than reach for commands.
Keep a dump somewhere else
A dump in the same folder you're removing goes to the Trash with it. Keep dumps with your other files, or on another disk, and name them with the database and the date so you can tell later what each one is.
Mistakes to avoid
A database's folder looks like any other folder in Finder, which is what makes these mistakes easy.
Don't move a data folder while the server runs
The server keeps its files open and writes to them constantly. Moving the folder, or anything in it, while it runs can corrupt the database. Stop the server first, in its app or with Homebrew's services.
Don't delete log files the database needs
pg_wal, MySQL's binary logs and SQLite's -wal files all have "log" in their names, and none of them is a log in the sense of a text record you can discard. Each is part of how the database keeps your data safe. Server logs, the text files listed in the first table, are the ones you can clear.
Don't press Initialize Database to free space
MySQL's preference pane recreates the data folder when you press it. Every database goes with it.
Don't assume uninstalling removes data
Homebrew and Postgres.app keep data folders after you remove the software, so that an uninstall never costs you a database. That's the safe default, and it's also why those folders outlive the servers that made them.
Don't touch apps' own databases
The SQLite files in your Library belong to Photos, Mail, Safari and every other app. They're not caches, and removing one can lose an app's library or history. Manage that data in the app, or see the post on Application Support for what's safe there.
How the app does it
Wombit shows these folders on its map, with sizes in which hard links and APFS clones count once. Select one to see what it is and what removing it would cost. It reads only names, sizes and dates, never what's inside a database, and file names and paths never leave your Mac.
Databases are data, and the app treats them that way:
- Postgres.app's folder and other apps' databases are inside Application Support, which is Review first. The app explains them and says to manage the data in the app that made it; nothing starts checked.
- Database servers installed with Homebrew are part of the Cellar, also Review first, explained with Homebrew's own way to uninstall them.
- Databases in Docker are inside Docker's disk file, which is Usually safe: the app explains what's inside and never moves the file.
Data folders in / and SQLite files in your projects have no catalog entry, so they're never offered for removal. On a Mac with Apple Intelligence, the inspector can give a Best guess at what one is, labelled as a guess.
~/
Library/ Application Support/ * Data that apps create and manage for you, such as libraries, databases, downloads and settings, in a folder for each app.
Review first · Explained only: the app shows you how
/
opt/ homebrew/ Cellar Command-line tools and libraries installed with Homebrew, in one folder for each package and version.
Review first · Explained only: never removed
~/
Library/ Containers/ com.docker.docker/ Data/ vms/ 0/ data/ Docker.raw Docker Desktop disk image (Docker.raw)
The virtual disk where Docker Desktop keeps all your images, containers, volumes and build cache.
Usually safe · Runs docker --context desktop-linux builder prune --force
Seeing and explaining all of this is free. The app doesn't remove any of these databases itself; it points to each tool's own way. Cleanup, for the caches and build files the catalog marks removable, is PRO, one $4.99 payment with lifetime access.
Every Pro tool's review is free to open, so you see what would go and why before you buy.
Frequently asked questions
Where is the Postgres data folder on a Mac?
Postgres.app keeps each server's data in ~/Library/Application Support/Postgres, in a folder named var- and the major version, such as var-17. Homebrew's PostgreSQL keeps it in /opt/homebrew/var, in a folder such as postgresql@17, or under /usr/local/var on an Intel Mac.
Why is my pg_wal folder so big?
PostgreSQL aims to keep its write-ahead log under 1 GB by default, but that's a soft target. A replication slot nobody reads, failing log archiving or a setting that keeps extra log can make it grow far beyond that. Fix the cause and PostgreSQL removes the old files at its next checkpoint; never delete them by hand.
Can I delete MySQL binlog files on my Mac?
MySQL removes binary logs older than 30 days by itself, when it starts or moves to a new log file. Its manual says you can delete them by hand, but that its own purge statement is better because it also updates the index of logs. If nothing replicates from your Mac, its configuration can keep them for less time or turn them off.
Does uninstalling Postgres.app delete my databases?
No. Dragging Postgres.app to the Trash leaves your data in ~/Library/Application Support/Postgres, and its documentation makes deleting that folder an optional step. Make a dump of anything you might want before you remove it.
Why didn't deleting data make my database smaller?
PostgreSQL, MySQL's shared tablespace, MongoDB and SQLite all keep freed space inside their files to reuse for new data. Each has its own way to give it back to the Mac: a full vacuum in PostgreSQL, compact in MongoDB, and a vacuum in SQLite. Dropping a whole database or table frees its files straight away.
Is it safe to delete Redis's dump.rdb file?
Only if you don't need what's in Redis. With the server stopped, Redis starts empty without it; with the server running, it writes a new one from memory at its next save. Copying the file first is safe, even while Redis runs.
What are .db-wal and .db-shm files on my Mac?
They belong to a SQLite database in write-ahead log mode: the -wal file holds recent changes and the -shm file indexes it. SQLite usually deletes both when the last connection closes. Never delete a -wal file by hand, because committed changes can be lost.
Does uninstalling PostgreSQL with Homebrew remove the data?
No. Homebrew removes the server but leaves its data folder in /opt/homebrew/var, so an uninstall never costs you a database. Remove that folder yourself, with the server stopped, once you're sure you don't need it.
Sources
- Go directly to a specific folder on Mac · Apple
- Installing and uninstalling Postgres.app · Postgres.app
- WAL configuration · PostgreSQL
- The binary log · MySQL
- Redis persistence · Redis
- Write-ahead logging · SQLite