Database guides

Aurora MySQL

Updated 2026-08-11 · 2 min read

AWS Aurora with the MySQL engine — wire-compatible with MySQL and served by the same driver, so the full MySQL toolset applies.

Amazon Aurora MySQL is a MySQL-compatible database on Amazon’s distributed storage layer. The wire protocol, the SQL surface and information_schema are MySQL’s, so AddisDB connects with its MySQL driver and everything behaves as it does on stock MySQL.

Who it is for

Aurora suits workloads that need more read throughput or faster failover than a single RDS instance provides. Storage replicates six ways across three availability zones and grows automatically; a replica is promoted in seconds.

As with Aurora PostgreSQL, a cluster has two endpoints and picking the wrong one is the classic first mistake. The writer endpoint accepts writes; the reader endpoint load-balances across replicas and is read-only. An INSERT that fails on the reader is Aurora refusing it, not the app.

Set up the cluster

  1. In the RDS console open the Aurora cluster and copy the writer endpoint — it contains cluster- in the hostname.
  2. Confirm the port, 3306 by default.
  3. Make sure you are inside the VPC or the cluster is publicly accessible, and that the security group allows your address on 3306.
  4. Note the master username, admin by default.
# @@innodb_read_only answers which endpoint you landed on
mysql -h my-cluster.cluster-abc123.us-east-1.rds.amazonaws.com -u admin -p -e 'SELECT @@innodb_read_only;'

Connect from AddisDB

  1. New Connection → Aurora MySQL. Port prefills to 3306 and username to admin.
  2. Paste the writer endpoint into Host unless you deliberately want a read-only session.
  3. Set SSL mode to require, or verify-full with the AWS regional CA bundle attached.
  4. If you are pointing at a reader on purpose, mark the connection read-only in AddisDB so writes are stopped before Aurora has to refuse them.
  5. Test, then Save.

What AddisDB gives you

The full MySQL toolset: schema tree, in-grid editing, structured create and alter table, database users, mock data, and query plans through EXPLAIN FORMAT=JSON.

The Live Monitor is real, reading information_schema.processlist for sessions and table sizes, with KILL available for cancelling or ending a session.

Statement statistics come from performance_schema, which Aurora enables by default on most instance classes.