What does a SQL monitoring tool actually need to watch?
Most SQL problems fall into four categories: the database process is down or crash-looping, queries are slow, connections are exhausted, or disk is filling up. A useful monitoring tool covers all four, not just uptime.
- •Process health: is MySQL or PostgreSQL running, and did it restart unexpectedly?
- •Slow queries: queries exceeding a threshold (commonly 1-2 seconds) logged and surfaced in alerts.
- •Connection usage: current connections vs. max_connections or max_connections for PostgreSQL; saturation above 80-90% is a warning sign.
- •Replication lag: seconds_behind_source (MySQL) or replay lag (PostgreSQL) trending upward.
- •Disk usage: data directory growth rate and time-to-full forecast.
- •Lock waits and deadlocks: queries blocked waiting for row or table locks.
- •Buffer pool or shared_buffers hit rate: a hit rate below 95% often means the buffer size is too small.
Without slow-query and connection monitoring, you will see the symptom (slow app) but not the cause. Disk forecasting matters because a database that fills its partition does not give a second chance.
What manual checks can you run without any tool?
Before you install anything, these commands give you a baseline on a running MySQL or PostgreSQL instance.
# MySQL: show running queries, connection count, and slow query status
mysql -e "SHOW PROCESSLIST;"
mysql -e "SHOW GLOBAL STATUS LIKE 'Threads_connected';"
mysql -e "SHOW GLOBAL STATUS LIKE 'Slow_queries';"
mysql -e "SHOW SLAVE STATUS\G" # replication lag
# PostgreSQL: show active queries and connection count
psql -c "SELECT pid, now() - pg_stat_activity.query_start AS duration, query, state FROM pg_stat_activity WHERE state != 'idle' ORDER BY duration DESC LIMIT 20;"
psql -c "SELECT count(*) FROM pg_stat_activity;"
# Disk: check how much space the data directory is using
du -sh /var/lib/mysql
du -sh /var/lib/postgresqlThese commands are point-in-time. You have to run them manually, and a slow query that finished before you looked is invisible. That is the core limitation of manual checks: they show the present, not a trend or a spike that already passed.
What criteria should you use to judge SQL monitoring tools?
The right tool for a small team running Linux servers without a dedicated SRE is not the same as the right tool for a database team of ten. Measure against these criteria before you commit.
- •Setup time: can it discover MySQL and PostgreSQL automatically, or do you write exporters and dashboards from scratch?
- •Alert quality: does it tell you the query, the threshold crossed, and the current value, or just 'database is slow'?
- •Trend and forecast: does it show you that disk grows 2 GB per day and will fill in 14 days?
- •Context alongside other signals: a slow query during a deploy is different from a slow query at 3 AM with no change. Does the tool know about deploys, restarts, and traffic changes?
- •Noise level: how many alerts per week require no action? Alert fatigue is the most common reason teams turn monitoring off.
- •Agent footprint: what does the agent do to the server it is monitoring? A heavy agent on a database host can itself cause the performance problems you are trying to catch.
- •Access model: does the agent need a database superuser, or a read-only monitoring account? Read-only is safer.
- •Price per server: some tools charge per host, some per metric, some per seat. At 5-20 servers the per-host model is usually cheaper and more predictable.
For teams also comparing the best server monitoring tools more broadly, the same criteria apply: automatic discovery, low noise, and a small agent footprint matter as much for CPU and memory as they do for SQL. See what Linux server monitoring should cover for the full checklist.
How does Opservo handle SQL monitoring?
Opservo auto-discovers MySQL, PostgreSQL, and Redis when the agent starts. No exporter to write, no dashboard to build. The agent is a static Go binary under 15 MB that opens no inbound ports; all traffic is outbound HTTPS with HMAC signing. It connects to databases with the minimum privilege needed for monitoring.
Each server gets an Opservo Health Standard score from 0 to 100, rated across Performance, Storage, Reliability, and Configuration. When a database metric crosses a threshold, the score drops and the report names the rule, the threshold, the current value, and the recommended fix. It is a deterministic rule engine, not a guess.
- •Process monitoring: alerts when MySQL or PostgreSQL stops or crash-loops.
- •Disk forecasting: predicts when the data directory fills based on current growth rate.
- •Anomaly detection on paid plans: learns each server's normal load, CPU, and memory for every hour of the day and alerts when behaviour is unusual, without you setting thresholds.
- •Plain-English explanations: tells you why a server is slow, what changed, and what to do.
- •One-click fixes: you approve the exact command; the agent re-checks that the problem cleared after applying it.
- •AI chat grounded in live server data: ask 'why is my database slow right now' and get an answer based on current metrics.
Opservo is built by Softuvo Solutions, an agency that runs production for 18 companies on the same platform. The free plan covers two servers with no card required. For teams monitoring several servers, setting up on-call alongside uptime monitoring rounds out the SQL monitoring picture.
What are the honest trade-offs between self-hosted and managed SQL monitoring?
Self-hosted tools like Prometheus with mysqld_exporter and a Grafana dashboard give you full control and no recurring cost per server. The trade-offs are real: you write the queries, maintain the exporters, set every threshold, and debug alerting rules yourself. For a team without a dedicated SRE, the maintenance burden often means dashboards go stale and alerts stop firing.
Managed tools take the maintenance work away but introduce a recurring cost, a dependency on an external service, and data leaving your server. For sensitive data, check what the tool stores: raw log lines, query text, or only aggregated metrics. Opservo's agent masks usernames and IPs in SSH events, stores only normalised log clusters rather than raw lines, and encrypts secrets at rest.
A middle path is a managed tool with a read-only agent and opt-in remote actions, so you get automatic discovery and plain-English alerts without giving the tool write access unless you choose to.
Last updated 2026-11-01.