From symptom to root cause in 90 seconds — here's the machinery.

Step 1 — You download the agent and run it

There is no sales call in this path and nothing to schedule. You create an account, download the agent for Windows, macOS or Ubuntu, and run it inside your network; it pairs itself back to your account on first start. Then you point it at a database with read-only credentials you create — so it is structurally incapable of writing to production, and revoking that user disconnects it completely.

Your data stays where it lives. The agent reads system catalogs, statistics views and performance counters — the operational surface, not your business rows. Database contents never leave your network in any configuration; see security for exactly what does and doesn't cross the boundary.

There's no instrumentation to install, no sidecar per query, no schema changes. If you can create a read-only user, you can connect a database in minutes.

Step 2 — Detection paths run every 90 seconds

A detection path is the core idea of the platform. When a veteran DBA investigates high latency, they don't guess: they check whether the plan changed, whether vacuum kept up, whether a lock chain formed, whether replication fell behind — in a specific order, ruling causes in or out on evidence. A detection path is that exact investigation, written down and encoded so it executes in seconds.

Where a detection path actually comes from

We'd rather tell you than let you guess, because the provenance is the product:

1. It starts as expert knowledge. The taxonomy of root causes and detection steps is derived from a DBA's 35 years of investigations — the trails he walked by hand, broken into their atomic units. That story is worth reading.
2. It is written and tested with AI assistance. We use AI to build the paths. We say so plainly, because the distinction that matters is the next line.
3. It is tested on real production servers, by real DBAs. Not on synthetic benchmarks. A path that hasn't survived a real database doesn't leave the workshop.
4. It is hashed and signed before release. If it isn't signed, it doesn't ship — and that applies to every one of us, founders included.
5. It executes with no model in the loop. This is the part people conflate. AI helped write it; nothing predicts, samples or guesses when it runs. Same evidence, same diagnosis, every time — and the evidence comes with it.

Every 90 seconds, the full library of detection paths relevant to your system runs against the live state. Nothing is trained, sampled, or predicted: the paths are deterministic — the same evidence always produces the same diagnosis, and every conclusion carries the evidence that produced it.

Step 3 — You receive a diagnosis, not an alert

When a detection path confirms a problem, what arrives is complete:

• Root cause — the actual why, stated plainly.
• Diagnostic evidence — the measurements, catalog state and the exact queries we ran, so you can verify rather than trust.
• Severity — the risk of doing nothing, so a short list of what actually matters replaces a long list of what merely exists.
• Resolution steps — the concrete actions that fix it, ordered, with the reasoning attached.
• The risk of applying them — each resolution path carries a risk level, and each step says whether it's reversible, what the rollback is, roughly how long it takes, and whether it needs confirmation before anyone touches it.

That last one is the difference between a diagnosis and a decision. Knowing that a config change fixes your problem is not enough to schedule it: you need to know whether it's a junior's ticket on Tuesday or a senior with a staging pass and a change window. Resolution paths are supervised or manual — your team applies them, and nothing runs against production on its own.

That's the "silver platter": the 2–4 hours of investigation that usually sits between an alert and a fix has already happened by the time you look.

Step 4 — And a history you can show your management

Diagnoses accumulate into scheduled reports — PDF or spreadsheet, daily, weekly or monthly, delivered to your inbox: what was found, what was fixed, what's still open.

This exists because of a lesson we learned expensively. A database expert's raw output is a working surface: tables, execution plans, filtered to whatever interests the expert. It is not something a manager can act on, budget against, or take upstairs — and a tool nobody upstairs can read is a tool that quietly gets cancelled. That is more or less how this company started.

What dbexpertAI is not

It is not a dashboard — keep Grafana, keep Datadog, they're good at rendering symptoms. It is not an alerting system — it will not page you about a threshold. And it is not an ML model guessing at correlations — that approach has been tried and it didn't survive contact with production. dbexpertAI occupies the layer those tools leave empty: autonomous diagnosis.

Which systems does this work on?

All five: PostgreSQL, MySQL, MariaDB, Oracle, SQL Server — same cadence, same root-cause-first reporting. Each system has its own path library, tuned to how that engine actually fails and tested against it; see the per-system pages for real examples.