MySQL

MySQL is a first-class engine in AddisDB, with a dedicated driver that also serves MariaDB, TiDB and SingleStore. Schema browsing, in-grid editing, live monitoring and mock data all work out of the box.

Who it is for

MySQL is the most widely deployed open-source database in the world, which is its real advantage: every host runs it, every framework targets it, and every operations question has already been answered by someone. It is fast at the read-heavy, straightforward workloads most web applications actually have.

The engine underneath is InnoDB — row-level locking, MVCC, crash recovery, and clustered indexes built on the primary key. That last detail shapes performance more than anything else: rows are physically ordered by primary key, so a sequential key keeps inserts appending at the end of the index rather than scattering across it.

Choose it when you want the widest possible hosting and tooling support, when your stack (WordPress, Laravel, Rails, older Django deployments) assumes it, or when your team already knows it well. Choose Postgres instead when you need richer types, stricter constraints, or an extension ecosystem.

Set up the server

1. Managed: create the instance on PlanetScale, Amazon RDS, Google Cloud SQL, Azure Database for MySQL or DigitalOcean, then copy the connection details from the provider’s Connect panel.
2. Add your IP to the firewall / allowed-hosts list.
3. Create a user your app is not using, so an exploratory session can never lock or exhaust the application’s pool.
4. Decide which host the account is allowed from. MySQL identities are user@host pairs, so an account created as 'addisdb'@'localhost' will not authenticate from your laptop no matter how right the password is.
5. Local: brew install mysql, apt install mysql-server, or Docker.

-- Give AddisDB a read-only account to start with
CREATE USER 'addisdb'@'%' IDENTIFIED BY 'a-strong-password';
GRANT SELECT, SHOW VIEW ON app.* TO 'addisdb'@'%';

-- and the two grants the Live Monitor wants
GRANT PROCESS ON *.* TO 'addisdb'@'%';
GRANT SELECT ON performance_schema.* TO 'addisdb'@'%';

# A local server in one line
docker run --name mysql -e MYSQL_ROOT_PASSWORD=secret -p 3306:3306 -d mysql:8

Connect from AddisDB

1. New Connection → MySQL. The port prefills to 3306 and the username to root.
2. Paste a mysql:// URL into the Connection URL box and click Fill fields, or type host, port, database, username and password by hand.
3. Managed MySQL usually needs SSL mode set to require.
4. Tag the Environment, click Test, then Save.

On macOS and Linux, MySQL servers installed through Homebrew show up in the Local server field so you can start and stop them from inside the app.

When the connection is refused

• "Access denied for user … (using password: YES)" — the password is wrong, or the account exists for a different host pattern than the one you are coming from.
• "Host … is not allowed to connect to this MySQL server" — no account matches your address at all. Create the user with a @'%' host, or the specific address.
• "Can't connect to MySQL server" with no further detail — bind-address is still 127.0.0.1, or a firewall is dropping 3306.
• An authentication-plugin error means the server and client disagree about the handshake. MySQL 8 defaults to caching_sha2_password; a proxy or very old server in between that only speaks mysql_native_password will fail before any query runs.

What AddisDB gives you

• Schema diagram of your tables and foreign keys, with saved per-project views.
• In-grid editing — change cells, insert, duplicate and delete rows behind the Edit toggle.
• Live Monitor — active queries, blocking, locks and connection stats sampled live, with an always-on flight recorder.
• Mock data generated from your real schema, tracked by primary key and removable in one click.
• Migrations and schema diff through Drizzle Kit or Prisma.
• AI that knows your tables and columns, plus one-click fixes for failing SQL.
• Read-only connections, prod tagging and destructive-statement detection.

Watching a database under load

The monitor reads the process list for what is executing, the performance schema for lock waits and blocking, and information_schema for per-table size. A statement that has been running for minutes and one that is blocked behind another look different in the panel, which is usually the distinction you are trying to make at 2am.