Skip to main content
Connect a MySQL database to let CloudThinker agents inspect schemas, indexes, table health, and slow queries by running SQL against it. You give CloudThinker one connection URL (MYSQL_URL) for a dedicated database user: agents can do what that user’s grants allow, and every write goes through Approvals first.

​
Prerequisites

  • A MySQL endpoint CloudThinker can reach from the internet, such as self-hosted MySQL, Amazon RDS for MySQL, or Cloud SQL for MySQL. Agents connect from CloudThinker Cloud, so localhost and private addresses resolve there, not on your network. See Reaching private services.
  • An admin account that can run CREATE USER and GRANT.
  • Performance Schema turned on if you want slow-query analysis. It’s on by default in self-hosted MySQL 5.7 and later. On Amazon RDS it depends on the performance_schema parameter in your parameter group.

​
Setup

1

Create a dedicated user

Connect as an admin and create a user for CloudThinker. % lets the user sign in from any host. To pin it to CloudThinker, create it once per egress IP instead, such as 'cloudthinker_readonly'@'203.0.113.10', and run the grants below for each. These docs don’t publish CloudThinker’s egress IP list: ask your CloudThinker contact, or contact us.
2

Grant read access

Grant read access to the database you want analyzed, plus the monitoring privileges agents need for sessions and query statistics:
GRANT takes effect right away, so you don’t need FLUSH PRIVILEGES. See Required permissions to add replication checks.
3

Check Performance Schema

Success state: the value is ON. If it’s OFF, set performance_schema = ON under [mysqld] in my.cnf and restart MySQL. On RDS or Cloud SQL, change it in the parameter group or database flags. The parameter is static, so it takes effect only after a reboot.
4

Open network access

Allow inbound connections on the MySQL port (default 3306) from CloudThinker’s egress IPs in your firewall, security group, or authorized networks list. A database that only listens on a private network needs a reachable endpoint first, since this connection has no private-link option.
5

Add the connection in CloudThinker

Open More → Workspace settings → Connections, select MySQL, and click Connect on its detail panel. In the dialog, optionally change the Alias and Description (agents read the description to pick the right database when you connect several). Paste the URL into MYSQL_URL and click Connect:
Success state: the connection shows Connecting and Verifying, then Connected. CloudThinker then runs Discovery once: a read-only look at the database whose results show in the Discovery section of the connection’s detail panel. It runs for at most 30 minutes.

​
Connection details

If the password contains @, :, /, or #, URL-encode it (for example, @ becomes %40), or the URL won’t parse.

​
Required permissions

Grant only the privileges for the capabilities you want.
Keep the user read-only. Never grant INSERT, UPDATE, DELETE, DROP, ALTER, or ALL PRIVILEGES unless you have a workflow that needs writes. See Write access.

​
Agent capabilities

​
Verify the connection

Expect a table of names, approximate row counts, and data and index sizes. An error that names a missing privilege tells you which grant to add.

​
Example prompts

​
Write access

CloudThinker classifies each SQL statement an agent sends before it runs.
  • SELECT, SHOW, DESCRIBE, EXPLAIN, and read-only WITH statements run without asking.
  • Any other statement, such as INSERT, UPDATE, or ALTER, counts as a write and goes through Approvals.
  • DELETE, DROP, and TRUNCATE count as destructive. A rule can ask first or refuse them.
  • An approved statement still fails if the user’s grants don’t allow it. A read-only user is the hard stop.
Every change an agent makes goes through your workspace’s Approvals first. On the default Auto · Rules + AI · Ask me mode, AI judgment can let a safe change run without asking — and an Allow Rule can too, once CloudThinker turns on Rule enforcement for your workspace. Choose Manual to approve every change yourself.

​
Troubleshooting

CloudThinker can’t reach the host. Check that the host and port in MYSQL_URL are public or otherwise reachable, that your firewall or security group allows CloudThinker, and that bind-address in my.cnf isn’t 127.0.0.1. On RDS, the instance must be publicly accessible or reachable through your network setup.
The user, password, or host part doesn’t match. A user created as 'cloudthinker_readonly'@'localhost' can’t sign in remotely, so create it with '%' or CloudThinker’s address range. Also check the password is URL-encoded in MYSQL_URL.
The user lacks a grant for what the agent tried. For slow queries, grant SELECT ON performance_schema.* and confirm SHOW VARIABLES LIKE 'performance_schema' returns ON. Performance Schema statistics reset on restart, so a freshly restarted server has little history.
The database name at the end of MYSQL_URL doesn’t exist or the user can’t see it. Run SHOW DATABASES; as that user and fix the name.

​
Security

  • Least privilege — grant only the permissions the agents need for your use case; start read-only and widen later.
  • Read-only by default — use read-only credentials unless you want agents to make changes through this connection.
  • Rotate credentials — rotate keys and tokens on your normal schedule; CloudThinker picks up the new value when you update the connection.
  • Revoke on offboarding — remove the credential at the provider when you delete a connection or a teammate leaves.
  • Scope grants to one database: grant SELECT on your_database.*, not *.*, so agents can’t read the mysql system schema or other apps’ data.
  • Require TLS on the server: set REQUIRE SSL on the user (ALTER USER ... REQUIRE SSL) when your server supports it, so credentials and results are encrypted in transit.

PostgreSQL

Connect PostgreSQL with a read-only user too. PostgreSQL runs in restricted mode, so it blocks writes even when they’re approved.

Approvals

Decide which database writes run, wait for a person, or are refused.