> ## Documentation Index > Fetch the complete documentation index at: https://docs.incident.io/llms.txt > Use this file to discover all available pages before exploring further. # MySQL > Query your MySQL database during an investigation to confirm what the data actually shows. Connect a MySQL database and Nexus can run read-only SQL against it, checking the rows directly when that's the fastest way to confirm a hypothesis. Is a record in the state the symptoms suggest? When did a value last change? You can connect a MySQL database directly with its own host and credentials, or connect [AWS](/nexus/telemetry/aws) and have your RDS and Aurora MySQL databases discovered for you. Both give the same read-only SQL access, so use AWS for databases on RDS or Aurora, and connect directly for anything else. ## What we support Nexus queries MySQL with read-only SQL. It writes the query, runs it for the window that matters, and reads back the results: joining across tables, filtering and aggregating, and reading from tables and views. ### Exploring your schema Nexus doesn't need you to describe your database. It learns the shape on its own: the tables you have, their columns and types, primary and foreign keys, and how tables relate. From there it explores progressively, starting with an overview of the database, then pulling fuller detail on the specific tables a question turns out to need, rather than loading everything up front. That keeps queries accurate against large schemas and grounded in tables that actually exist. How Nexus learns and uses this structure is covered in [How telemetry works](/nexus/telemetry/how-it-works#learning-your-stack). Nexus only ever reads from your database; it never writes. Connect with a **read-only** database user so that guarantee is enforced on your side, not just trusted. ## Security Nexus queries your database to read from it, never to change it, and that guarantee is enforced in several independent layers rather than left to trust. **Every query runs on a read-only connection.** Each query runs on its own fresh connection opened in read-only transaction mode, so there's no long-lived session that could be left in a writable state. We recommend connecting a read-only database user too, so the guarantee holds on your side as well. **Every query is parsed and checked before it runs.** Each query is parsed with a real MySQL parser and must be a single `SELECT`. Anything that writes or changes structure, bundles multiple statements into one request, or reaches a write path another way (such as a write hidden in a subquery) is rejected. **Queries can't overload your database.** Every query runs under a timeout and returns a capped number of rows, so a broad or expensive query stays bounded rather than running away. Each query gets its own short-lived connection that we open, use once, and close, so we never hold idle connections open to your database. And we give up quickly on a database we can't reach. For more on how we handle your data during AI processing, see our [Trust Center](https://trust.incident.io/). ## Connecting MySQL You can either connect a database directly with its connection details, or connect AWS and let it discover your RDS and Aurora databases. ### Directly **What you'll need:** * The **host** and **port** of your database (port defaults to 3306). * The **database name** to connect to. * A **username** and **password**. * The **TLS mode** to use, and any **client certificate**, **client key**, or **CA certificate** your database requires. Mutual TLS is supported for environments that need it, and a client certificate can stand in for the password. 1. From the [Nexus telemetry settings](https://app.incident.io/~/nexus/telemetry), add a telemetry data source and choose **MySQL**. 2. If the database isn't reachable from the public internet, which is the common case, set **Network access** to **Private network** and route through a [proxy](/integrations/proxy) you run in your network. 3. Enter the connection details and credentials, or paste a full connection string to fill the fields in one go, then test the connection. The test passes only when the user can log in and read at least one table. 4. Once connected, the database is enabled for Nexus. You can disable it at any time. ### Through AWS (RDS and Aurora) Connect [AWS](/nexus/telemetry/aws) with **RDS** among the selected services, and your databases are discovered for you. Discovery covers the MySQL and Aurora MySQL engines: one selection covers both, and an `aurora-mysql` cluster appears as a MySQL data source alongside plain RDS instances rather than as a separate Aurora type. Discovery finds the databases and their endpoints, but not a way to log into them. So each discovered database needs a login, which you choose per database once it appears: * **RDS IAM.** Give the role or user incident.io authenticates as `rds-db:connect` on the database user you want it to log in as. Each connection mints a short-lived token, so there's no password stored with us. Connections verify the server against the AWS RDS trust bundle, which we ship, so you don't need to supply a CA. You'll need IAM authentication enabled on the database and a database user set up for it. See AWS's guide to [IAM database authentication](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.html). * **Username and password.** Provide credentials for a database user as you would for a direct connection. If a database isn't reachable from the public internet, attach a [proxy](/integrations/proxy) to the AWS connection. Discovered databases are disabled by default, so review what's found and enable the ones worth querying during an incident. ## Best practice * Connect a **read-only** user. Nexus only ever reads, and a read-only user makes that enforceable on your side. * On a direct connection, point it at a **replica** rather than your primary, so investigation queries never compete with production traffic. Databases discovered through AWS currently always connect to the primary. * Grant access to the tables Nexus should see and no more. It explores only what the user can read. * On RDS and Aurora, prefer **RDS IAM** over a stored password, so there's no long-lived credential to rotate. ## Related Discover your RDS and Aurora databases. How providers and data sources fit together. How Nexus explores your schema and queries your data.