IndigoStack

Migrating from MySQL 5.7 to MariaDB

MySQL 5.7 is no longer included in Indigo. Oracle never released it for Apple silicon, so when Indigo moved to Apple-silicon-only builds, 5.7 had to stay behind. The recommended replacement is MariaDB 10.11, which is compatible with most apps built for MySQL 5.7.

The good news:

  • Your data is safe. An existing MySQL 5.7 service keeps working, and your databases stay on disk. Indigo will refuse to rebuild a 5.7 service (there is nothing left to rebuild it from), so a rebuild can’t destroy it — you’ll simply see a message explaining the situation, with nothing deleted.
  • The migration is small. Export each database, import it into MariaDB, point your app at the new service. For most stacks this is a 15-minute job.

If you’re on an Apple silicon Mac: don’t put this off

MySQL 5.7’s server binary is Intel-only, so on an Apple silicon Mac it runs through Rosetta. That works today, but Apple is winding Rosetta back in coming macOS releases — a stranded 5.7 service is living on borrowed time. A 5.7 service also can’t move to a new Mac. Migrating now, while the old service still starts, is much easier than migrating after it won’t.

Before you start

  • Your stack must be running (both the MySQL service and, once added, the MariaDB service) — exports and imports talk to the live servers.
  • MariaDB in Indigo requires Indigo Pro.
  • Indigo ships two MariaDB versions. For apps built against MySQL 5.7, choose MariaDB 10.11 — it’s the version with the strongest 5.7 compatibility, and the one Indigo recommends.

Step 1: Add MariaDB 10.11 to the stack

  1. Select your stack, then click the + button beneath the service rack (or double-click an empty spot in the rack).
  2. In the Add services screen, choose MariaDB 10.11.
  3. Start the new service.

MariaDB runs happily alongside your existing MySQL 5.7 service — they get different ports, so nothing conflicts while you migrate.

Step 2: Export your MySQL databases

The easy way: select the MySQL 5.7 service and open its databases list, then drag a database to your Desktop. Indigo dumps it into a compressed file named like my-database-2026-08-19-1424.sql.gz. Repeat for each database your apps use (you don’t need the system databases — mysql, sys, information_schema, performance_schema).

Prefer the command line? indigo exec runs a command with the stack’s services on PATH. Give it the connection details from the MySQL service’s Reference tab — the port is the one Indigo assigned, so it won’t be 3306:

indigo exec -s "My stack" -- mysqldump -h 127.0.0.1 -P 50000 -u root -p --databases my_database > my_database.sql

The --databases flag makes the dump self-contained — it includes the CREATE DATABASE statement, so the import step needs no preparation.

Why this one needs the connection details

A bare mysqldump my_database fails here with Can’t connect to local MySQL server through socket ‘/tmp/mysql.sock’. Indigo gives each database service its own port and socket, and a MySQL 5.7 service built by Indigo 1.x predates the shell integration that passes those along automatically — so the client falls back to a default socket that isn’t there. Current services, MariaDB included, don’t have this problem.

Step 3: Import into MariaDB

The easy way: drag the exported file onto the MariaDB service’s databases list. Indigo creates a new database (named from the file) and imports into it. Both .sql and .sql.gz files work — including the compressed files from Step 2. Dropping onto an existing database replaces its contents instead, after asking you to confirm.

The command-line equivalent, using the self-contained dump from Step 2. No connection details needed this time — MariaDB is a current Indigo service, so indigo exec hands it its own host, port and credentials:

indigo exec -s "My stack" -- mariadb < my_database.sql

For a compressed export, uncompress it on the way through:

gunzip -c my-database-2026-08-19-1424.sql.gz | indigo exec -s "My stack" -- mariadb

Which server do the commands reach?

While both services are in the stack, the mysql and mysqldump command names belong to the MySQL service, and mariadb / mariadb-dump reach MariaDB — so the commands above line up naturally. Once MySQL is removed (Step 6), MariaDB’s MySQL compatibility commands setting (on by default) takes over the mysql and mysqldump names, so your scripts and muscle memory keep working.

A quick check that everything arrived:

indigo exec -s "My stack" -- mariadb -e "SHOW DATABASES; SELECT COUNT(*) FROM my_database.some_table;"

Step 4: Update your app’s configuration

Point your app at the MariaDB service instead of MySQL. Select the MariaDB service and open its Reference tab — it shows the connection details, ready to copy:

  • Host: 127.0.0.1
  • Port: the service’s port (this will differ from the MySQL service’s port)
  • Username: root, with the root password shown alongside

The Reference tab also generates a ready-made config snippet for your framework. Notes for the common ones:

  • Laravel: set DB_CONNECTION=mariadb (Laravel 11+). Laravel 10 and older have no mariadb driver — keep DB_CONNECTION=mysql there; it works fine against MariaDB.
  • Symfony (Doctrine): include the server version in your DATABASE_URL so Doctrine generates the right SQL, e.g. serverVersion=mariadb-10.11.18. The Reference tab’s generated snippet has the exact value.
  • Everything else (WordPress, Drupal, plain PDO/mysqli, …): no driver change — just update the port (and password, if it differs). MariaDB speaks the MySQL protocol.

Step 5: Test

Run your apps against the new service. Browse the site, run your test suite, run a migration — whatever exercises the database. Most apps built for MySQL 5.7 work unchanged on MariaDB 10.11; if your app uses 5.7-specific edge cases (for example, particular JSON functions), this is the moment they’d surface, while your MySQL service and its data are still intact as a fallback.

Step 6: Remove the MySQL service

Once everything checks out, select the MySQL service in the rack and click the − button beneath it. Indigo asks you to confirm, and shuts the stack down to do it; start it again afterwards.

Two things worth knowing: your exported .sql.gz files make a fine last-line backup, so keep them somewhere safe for a while — and removing the service does not delete its data directory, which stays in the stack’s folder until you remove it yourself.

With MySQL gone, MariaDB’s MySQL compatibility commands take over the mysql and mysqldump names, so any scripts or habits that used them keep working — now pointed at MariaDB.

That’s it — you’re on a database that’s built for your Mac, and that Indigo can rebuild, upgrade, and move to a new machine.