DBGorilla Now Supports MySQL

When we launched DBGorilla, we said MySQL was coming very soon. Turns out we actually meant very soon. DBGorilla now supports MySQL alongside Postgres.

We built the MySQL support around the same idea that led us to build DBGorilla for Postgres in the first place. Monitoring can tell you that CPU is climbing, a query is slowing down, or the database suddenly has a connection problem. The useful work starts when someone has to figure out why.

That investigation usually lands with the same small group of people. Someone has to inspect the query, look at the execution plan, understand what the optimizer decided, check the indexes and configuration, and work backward from the symptom until there is an explanation that actually makes sense.

DBGorilla is built to do more of that work before the investigation lands on your team. Now it can do it with MySQL too.

DBGorilla monitors MySQL and helps investigate what changed

MySQL has its own optimizer, execution plans, statistics, configuration, and performance behavior. Supporting MySQL was not a matter of pointing the Postgres agent at a different port and hoping for the best.

You run the DBGorilla collector inside your own environment, with a read-only login, and it sends telemetry back to us. That is what gives the agent the context to investigate what is actually happening in that environment. When performance changes, the goal is to move past the symptom and understand the query, plan, indexes, configuration, and database conditions behind it.

That matters because the same SQL can behave very differently depending on the database underneath it. A query that looks completely reasonable in code can examine far more rows than expected, use a different access path as the data grows, or become expensive simply because it runs often enough for a small inefficiency to become a large one.

You do not need another alert explaining that MySQL is unhappy. You need somewhere useful to start.

Find the queries doing more work than they should

The query causing the most pain is not always the query with the slowest individual execution.

A query that takes a few milliseconds may look harmless until it runs hundreds of thousands of times. Another query may return ten rows while examining hundreds of thousands to get there. Both technically work, and neither necessarily looks alarming in the application code.

DBGorilla gives the team a way to investigate that behavior with the database context already available. Engineers can look at query performance, execution plans, row estimates, index usage, and other signals together instead of copying pieces of the problem into a generic AI assistant and asking it to guess what the database is doing.

That is especially useful as more SQL gets written by coding agents. The agent can see the code you gave it. That does not mean it knows the workload, data distribution, indexes, or optimizer decisions inside the database where that code is going to run.

Understand why MySQL made the decision it made

One of the more entertaining database conversations starts with, “The index is right there. Why the hell isn’t it using it?”

Usually there is a reason. The predicate may make the index difficult to use. A composite index may not match the way the query accesses the data. The optimizer may decide that enough of the table matches that scanning it is actually cheaper.

The interesting question is not whether an index exists. It is why MySQL chose the plan it chose.

DBGorilla’s query analysis gives engineers a way to work through that question against what your database is actually doing. Instead of immediately adding another index, forcing one into the query, or making a configuration change because somebody found the same error message on Stack Overflow in 2017, the team can start with the evidence from its own environment.

Connection and configuration problems need context too

The same thing happens when the problem looks like configuration. Take Too many connections. Raising max_connections is an obvious response, but it does not tell you why the connections are there or whether giving an already busy database more of them is going to make anything better.

The cause could sit in the database, the application, the connection pool, or the way those pieces interact. The useful work is figuring out which one before turning a knob.

DBGorilla’s health monitoring and AI DBA bring that broader database context into the investigation. Engineers can ask about configuration, resources, schema, queries, indexes, and performance without starting from zero every time a new symptom appears.

The database expert still decides what happens next

Adding MySQL does not change one of the decisions we made early with DBGorilla. The point is not to replace the DBA or the engineer who understands the database better than anyone else on the team.

The point is to stop making that person personally reconstruct every routine investigation before anyone else can move. DBGorilla gathers the context, works through the problem, and gives the team something useful to review. For supported workflows, changes can be tested safely on an isolated clone before production, so the recommendation comes with evidence rather than another opinion about what should probably work.

Your engineers still decide what ships. We think that is a feature.

Give DBGorilla for MySQL a try

DBGorilla now supports both Postgres and MySQL, with Free, Pro, Business, and Enterprise options. New Free accounts also get 30 days of Pro free with no credit card required.

Point a collector at a MySQL database and give it the work your team is already dealing with: slow queries, questionable indexes, configuration problems, strange execution plans, connection issues, and whatever has been sitting in the “someone should probably look at that” pile.

Then tell us what worked, what did not, and where you managed to break it.