The best database for a Mac is the one you will run in production: Postgres.app or Homebrew for a native PostgreSQL, Homebrew for MySQL, Docker when you want disposable or versioned instances, and the sqlite3 that already ships with macOS for anything that fits in a file.
Macs are excellent development machines and awkward database servers, mostly because there are five reasonable ways to install the same thing and they fight over port 5432. This guide picks a sensible default for each engine, shows the commands, and covers the graphical clients worth installing. Then it deals with the problem that costs teams real time: a database that behaves on your laptop and differently in production. Getting a local setup that mirrors the real thing is dull work and the most valuable database work you will do this year.
Table of contents
- Pick the engine first, then the installer
- PostgreSQL on a Mac: Postgres.app or Homebrew
- MySQL on a Mac with Homebrew
- Docker: disposable, versioned, and the best parity tool
- GUI clients worth installing
- Keep your local database honest with production
- How this fits the rest of the stack
- FAQ
Pick the engine first, then the installer
Before installing anything, decide what the database is for. A local script, a desktop tool or a small side project that one person uses is a fine fit for SQLite: it is a single file, has no server, and macOS already includes the sqlite3 command. A web application that will run on a server in production wants the same engine locally, and that means PostgreSQL or MySQL.
The mistake is choosing on convenience today. Developers who prototype with SQLite and deploy on Postgres find out about the difference in types, locking, concurrent writes and date handling at the worst time. The SQLite versus PostgreSQL comparison goes through those differences in detail. The short version is that SQLite is a great database that is the wrong rehearsal for a server database.
There are four ways to run a server database on a Mac. Postgres.app is a self-contained application for PostgreSQL only. Homebrew installs Postgres or MySQL as a background service you manage from the terminal. Docker runs any engine in a container you can throw away. A packaged installer from the vendor exists for both, but it is the option most likely to leave files scattered across the system, so it is the one to skip.
Pick one installer per engine and stay with it. Running Postgres.app, a Homebrew Postgres and a Docker Postgres at once is how people end up connecting to the wrong instance and wondering where their tables went.
PostgreSQL on a Mac: Postgres.app or Homebrew
Postgres.app is the gentlest route. You download the application, move it to Applications, open it and click Initialize. It runs a server on port 5432 and keeps multiple major versions side by side, which is helpful when a project pins an older release. It works on both Apple Silicon and Intel Macs. The one step people skip is adding its command-line tools to the PATH, without which psql resolves to whatever else is installed. The Postgres.app setup guide covers that in full.
Homebrew suits people who live in the terminal and want the database managed like any other service.
brew install postgresql@18
brew services start postgresql@18
# create a database and connect
createdb myapp_dev
psql myapp_devHomebrew formulas for versioned packages are keg-only, so you may need to add the bin directory to your PATH, and the install prints the exact line. On a fresh install your macOS username is a superuser with no password, which is fine locally and a habit you should not carry into any shared environment.
Whichever you choose, use a real connection string in your application and keep it in an environment variable, not in code. It makes the switch to a hosted database a one-line change.
export DATABASE_URL="postgres://localhost:5432/myapp_dev"MySQL on a Mac with Homebrew
For MySQL, Homebrew is the standard answer. It installs the server and client, and brew services manages the background process.
brew install mysql
brew services start mysql
# set the root password and tidy the defaults
mysql_secure_installation
mysql -u root -p
mysql> CREATE DATABASE myapp_dev CHARACTER SET utf8mb4;Two Mac-specific issues come up repeatedly. The first is a socket error, when the client looks for the socket in a different place than the server created it. Connecting over TCP with -h 127.0.0.1 sidesteps it. The second is authentication: MySQL 8 defaults to caching_sha2_password, which some older client libraries cannot use, and the symptom is a confusing authentication plugin error from your application. Updating the client library is the right fix, rather than weakening the user.
If you would rather not have a MySQL server running all day on a laptop, that is a good reason to use Docker for this engine specifically. The server starts when you need it and disappears when you do not, with your data kept in a named volume.
Docker: disposable, versioned, and the best parity tool
A containerised database gives you the exact major version you run in production, the ability to reset to a clean state in seconds, and no changes to the rest of your system. On a Mac that means Docker Desktop or one of the lighter alternatives, and images for Postgres and MySQL both ship for Apple Silicon.
# docker-compose.yml
services:
db:
image: postgres:17
environment:
POSTGRES_USER: app
POSTGRES_PASSWORD: localdev
POSTGRES_DB: myapp_dev
ports:
- "5433:5432"
volumes:
- pgdata:/var/lib/postgresql/data
volumes:
pgdata:Notice the host port is 5433, not 5432. If Postgres.app or Homebrew is already listening on 5432, a container that also asks for it fails to start, or worse, you connect to the wrong server. Mapping to a different host port removes the ambiguity. Run docker compose up -d, and reset everything with docker compose down -v when you want a clean slate.
The trade-offs are real. Docker uses memory on a laptop, file mounts on macOS can be slow for write-heavy workloads, and losing the volume loses the data. Put anything you cannot recreate from migrations and seed scripts somewhere safer. Treat a local database as disposable and your setup will be much more robust, since a fresh clone should be able to rebuild it from scratch in one command. A Makefile target or an npm script that runs compose up, applies migrations and loads seed data is a ten-minute investment that pays back every time a new teammate joins or a bad migration needs to be thrown away.
GUI clients worth installing
You can do everything in psql and the mysql client, and you should know how, but a graphical client makes browsing tables, editing rows and running queries faster. There is no single best choice, so here is how they differ in practice.
- TablePlus is a native, fast client that handles Postgres, MySQL, SQLite and more from one window, and it is popular on the Mac for its speed.
- DBeaver is a free, open-source client that supports nearly every database. It is heavier because it runs on Java, and it has the most features, including an ER diagram view.
- pgAdmin is the official PostgreSQL administration tool. It is thorough for administration tasks, though it is web-based and feels slower for quick queries.
- Postico is a Postgres-only native client with a tidy interface, and Sequel Ace plays the same role for MySQL and is free.
- DataGrip, the JetBrains client, is the strongest option if you already live in their IDEs and want good autocomplete.
For SQLite, DB Browser for SQLite is a simple free choice, and most of the clients above open SQLite files too. Whichever you pick, save your connections with clear names such as local-postgres and staging, and make production read-only or leave it out entirely. The number of incidents caused by a stray DELETE in a client connected to the wrong database is not small.
Keep your local database honest with production
Parity is the point of all this. Match the engine and the major version first: Postgres 17 locally and Postgres 15 in production is a bug waiting for a date to arrive. Match extensions next. If your app uses pg_trgm or uuid-ossp, install them locally and enable them in a migration, not by hand. Match collation and timezone, because sorting and date maths differ silently when they do not.
Use migrations for every schema change, checked into the repository, so any environment can be rebuilt from nothing. Seed data belongs in a script, not in a dump file that only exists on one laptop. And keep the connection string in an environment variable so the same code talks to a local database on your Mac and a hosted one in production.
When you move to a real server, do not point your laptop at production to test things. Use a separate staging database of the same engine, restrict it with an IP allow list, and connect through the same GUI client. The free hosted PostgreSQL guide covers options for a hosted instance to graduate to.
How this fits the rest of the stack
Once the app works locally, the production step is a managed database of the same engine and a service that reads its connection string from an environment variable. The RunxBuild hosting calculator shows what a managed Postgres or MySQL instance and a service cost together, so you know the number before your side project becomes a line item. Create the instance from the RunxBuild dashboard, then use the managed database documentation for versions and connection details and the network security page to lock access to your own IP while you test from your Mac. Export your local data with pg_dump or mysqldump, restore it into the hosted instance, and your laptop and production finally agree. From there, keep the habit: rebuild the local database from migrations regularly, and if it ever cannot be rebuilt, treat that as a bug in your process rather than a fact of life.
Useful related references:
FAQ
What is the best database for a Mac?
For web development, use the same engine as production, usually PostgreSQL or MySQL. Postgres.app or Homebrew is the easiest native route, and Docker is best for disposable or version-pinned instances. For single-user tools, SQLite is built into macOS and needs no server at all.
How do I install PostgreSQL on a Mac?
Either download Postgres.app, drag it to Applications and click Initialize, or run brew install postgresql@18 followed by brew services start postgresql@18. Then create a database with createdb and connect with psql. Add the tools to your PATH so psql points at the right version.
Is SQLite installed on macOS?
Yes. macOS includes the sqlite3 command-line tool, so you can create and query a database file straight from the terminal without installing anything. It is ideal for small local tools, but it is not a good rehearsal for a server database such as Postgres.
What is a good free database GUI for Mac?
DBeaver Community is free and works with most databases. pgAdmin is free for PostgreSQL, Sequel Ace is free for MySQL, and DB Browser for SQLite is free for SQLite. TablePlus and Postico are popular native alternatives if you prefer a lighter interface.
Should I use Docker for a local database on Mac?
Use it when you want the exact production version, a clean reset in seconds, or several versions at once. Map the host port to something other than 5432 to avoid clashes, keep data in a named volume, and remember that files on a Mac mount can be slower for write-heavy work.