AI SRE for Databases

Many production incidents are database incidents. A query that used to be fast is suddenly slow, a migration that looked clean in review changes a plan, a replica that was in sync yesterday falls behind. The hard part is rarely writing the fix. It is finding which of hundreds of possible causes is the real one.

Sherlocks AI uses your databases as a primary signal source. When an alert lands in Slack, 16+ AI agents correlate query performance, connection pools, replication state and recent changes, test hypotheses against the data, and deliver a draft root cause analysis in your incident channel.

Database incidents are usually reported by something other than the database. A worker gets OOMKilled, an API times out, a connection pool empties, and the first alert names the application. Underneath, the cause sits in one of three layers that behave differently: storage, where a volume hits a throughput or IOPS ceiling; queries, where one plan regression changes the cost of a statement by two orders of magnitude; and connections, where the pool is a symptom rather than a cause.

So the on-call engineer opens pg_stat_statements, reads a query plan, checks replica lag and the storage metrics, and rules out the obvious first guesses one at a time. Raising the pool size on a plan regression just moves the failure into the database.

That checking is the part Sherlocks AI takes over. It generates hypotheses about the root cause, tests them against the data, and ranks them by likelihood and impact, so the engineer verifies the reasoning instead of redoing it.

The database failure classes teams hit most. Each group sits next to published database investigations, with the RCA guide and upstream documentation for each.

1. 1Step 1: Connect your databases, read-only.

   Add them as integrations alongside the rest of your stack. Access is read-only and limited to metadata queries.

2. 2Step 2: Install the Slack app.

   Sherlocks AI monitors your Slack workspace for incident conversations, questions and alerts, so the database alerts your team already sends to Slack are where an investigation starts.

3. 3Step 3: An alert fires.

   An investigation is triggered manually, by the alert, or proactively. Watson reads query performance, connection pool and replication signals, then Sherlocks AI generates hypotheses, tests them against the data, and ranks causes by likelihood and impact.

4. 4Step 4: The RCA lands in Slack.

   The primary root cause with a confidence level, contributing factors, a timeline, recommended remediation, and links to the relevant logs, metrics, commits and dashboards. Engineers ask follow-up questions in the same thread.

Running on a cloud provider? The AWS, Google Cloud and Azure pages cover RDS and Aurora, Cloud SQL and Azure SQL in more depth.

This is a published case from the examples section, not a mock-up. A connection pool alert fired at 100%, and the obvious first guesses were wrong. Here is how the investigation got from the pool alert to the missing index.

1. 1The alert
   CriticalPrometheus JMX Exporter + Grafana2026-03-29 10:22 IST

   HikariCP active connections at 100% (50/50) for > 2 minutes

   50/50

   Active Conns

   42s (was 50ms)

   Query Time

   2,891

   HTTP 503s
2. 24 hypotheses ruled out
   • ✕

     Connection leak: app borrows connections and never releases them

     All 150 connections are in 'active' state executing queries, not idle or leaked. After the index fix, pools drained within 2 minutes, proving connections were released normally.

   • ✕

     Connection pool simply sized too small (config problem)

     At 50ms/query, 85 req/sec needs only ~4 concurrent connections, far inside 150. The pool is not the constraint. After the index dropped query time to 12ms the pool drained immediately.

   • ✕

     Traffic spike alone overwhelmed the service

     The spike only mattered because it exposed a latent regression. At 50ms, 85 req/sec is trivial for a 150-connection pool. Ruled out as a standalone cause; it is the trigger, not the cause.

   • ✕

     Database statistics are stale causing poor query plans

     Running ANALYZE did not change the query plan; the issue is structurally a missing index, not stale stats.

3. 3Root cause

   Flyway V32 added region without an index while the query was changed to filter by it

   V32 added the region column and backfilled but the CREATE INDEX line was omitted. The query was simultaneously changed to filter by region first, bypassing idx_users_status and forcing a Seq Scan on 5M rows (42s). Pool exhausted, 2,891 HTTP 503s.

4. 4The fix
   • Create composite index on (region, status, last_login) immediately to resolve the sequential scan.
   • Add a Flyway migration review checklist: any new WHERE clause column must have a corresponding index.

For the general method, read how to debug connection pool exhaustion, or browse every database investigation.