Install MySQL 8.4 on Apple Silicon with Homebrew

This walkthrough targets a fresh MySQL 8.4 development installation on an Apple Silicon Mac using Homebrew. It chooses a named release series instead of an unversioned package that may follow another major version. Check current Homebrew macOS requirements and the formula’s available maintenance release before installing. This is not a migration procedure for an existing MySQL or MariaDB server.

The installation commands were checked against Homebrew and MySQL documentation. They were not executed to install or change a service during this revision. In particular, no existing database, user, password, configuration file, or data directory was changed to test these instructions.

1. Inventory the Mac before installing

Use the official Homebrew installation instructions if the package manager is absent. Then inspect the platform and existing packages/services:

uname -m
brew --prefix
brew list --versions
brew services list
lsof -nP -iTCP:3306 -sTCP:LISTEN
ls -ld /usr/local/mysql /tmp/mysql.sock
brew_prefix="$(brew --prefix)"
ls -ld "$brew_prefix/var/mysql"
ls -l /etc/my.cnf /etc/mysql/my.cnf "$brew_prefix/etc/my.cnf" "$HOME/.my.cnf"

Read each result separately; missing paths can produce expected “not found” messages. Native Apple Silicon Homebrew normally uses /opt/homebrew. Look for mysql, [email protected], other MySQL series, MariaDB, Oracle’s native package, and a running socket or port. The Homebrew MySQL variants use the same default var/mysql data location, so a different formula name does not by itself isolate old data.

If any database installation or populated data directory already exists, stop this fresh-install path. Identify its version, service owner, configuration, and backup/restore procedure. An old /etc/my.cnf can affect a Homebrew server. Do not overwrite that file, delete the data directory, kill a listener, or start a second server against the same files. No TCP listener is not proof of an empty machine.

2. Install the explicitly selected release

brew info [email protected]
brew install [email protected]
mysql84_prefix="$(brew --prefix [email protected])"
"$mysql84_prefix/bin/mysql" --version

The MySQL 8.4 formula is keg-only. Explicit binary paths prevent accidentally using a client from another installation and avoid force-linking over working tools. Installing binaries does not safely migrate existing data to a new major release. The reported client version is also not proof of which server an application connects to.

3. Start the new local service deliberately

brew services start [email protected]
brew services list

Run these only after the fresh-install checks. The service starts now and is registered for login under the current user. Routine Homebrew service management should not be prefixed with sudo. If startup fails, inspect this service’s log and conflicting option files; do not paste a generic tuning block into a system-wide configuration file.

4. Identify and secure the intended instance

The formula documents a fresh installation without a root password and localhost-only connections. That describes the new default installation, not every server on a Mac. Connect to the new local instance only after ensuring there is no other MySQL socket/service:

"$mysql84_prefix/bin/mysql" -u root

SELECT VERSION(), CURRENT_USER(), @@hostname, @@port, @@datadir, @@socket;
SHOW VARIABLES LIKE 'bind_address';

Confirm the 8.4 server, intended Homebrew data path, socket, and local network binding. Record the actual socket path, then exit with \q. If the result identifies another server, do not run the security utility against it. For the confirmed new instance, run the versioned utility with that exact socket path:

"$mysql84_prefix/bin/mysql_secure_installation" --socket=/path/from/the/socket/result

Replace the path with the observed value before running it. The security utility can set the root password and offer removal of anonymous accounts, remote root access, and the test database. Review the prompts; this mutates the selected server. Enter passwords interactively, never in the command line, article, or shell history. Reconnect using the same confirmed socket and -u root -p to verify the credentials.

Use a separate application account with only the permissions the application needs, rather than storing the administrator’s credentials in application code. Keep this development server local. Enabling remote access requires a separate network, TLS, and account design; changing bind-address alone is not that design.

5. Keep defaults until there is measured evidence

Do not disable the Performance Schema or binary logging just to copy a speed recommendation. Monitoring, recovery, replication, memory, and timeout settings have different purposes. innodb_dedicated_server assumes a dedicated server, which a development laptop usually is not. First identify a slow query and inspect its plan and resource use; changing hundreds of connection or cache settings can create larger problems.

The option-file reference explains search order and server/client groups. Edit only the confirmed instance’s intended file, preserve its previous contents, and plan any required restart around active applications. Stop this development service with brew services stop [email protected] only when its users no longer need it; stopping does not delete the databases.

Upgrade and troubleshooting boundaries

For an upgrade, use MySQL’s supported source-to-target path and compatibility checks, test a restore, and retain a rollback plan. A Homebrew package upgrade is not evidence that application behavior or database compatibility has been verified. If authentication fails, first check the socket, account, and server identity. If a port is occupied, identify the service instead of terminating it. If the data directory exists, preserve it and switch to a documented migration or recovery workflow.