Seven advisors.
One database fleet.
DBHelm turns raw telemetry into decisions: what to fix, what to upgrade, what to right-size, what's running hot right now. No extra agents. No PromQL. No cloud roundtrip.
Incident Playbooks
Your on-call runbooks, as code.
The problem
Every team has the same 3am incidents — high CPU, replication lag, connection exhaustion — and every team writes a private wiki page nobody reads at 3am.
What DBHelm does
Five built-in diagnostic playbooks that auto-run against any K8s-discovered database via kubectl exec, collect findings, rank by severity, and hand you an incident report with recommendations and a session-scoped execution history.
-
Five pre-built playbooks
High CPU, Replication Lag, Connection Exhaustion, Disk Space, Slow Queries — ready on day one. Direct-connect DBs not supported today (kubectl exec required).
-
Auto-run diagnostic steps
Each playbook executes a fixed sequence of checks inside the pod — no click-through, no copy-paste.
-
Severity-ranked findings
Critical / Warning / Info, with root-cause hints from the actual engine output.
-
Execution history
Every run is stored in-process with timestamp, database, outcome, and findings. Session-scoped today; persistent audit trail is on the roadmap.
DR Testing
Can you actually fail over? Score it.
The problem
"We have backups" is not a DR plan. Most teams discover at the wrong moment that backups are stale, replicas are lagging, or nobody knows which host is the primary.
What DBHelm does
A readiness score from 0 to 100 for every K8s-discovered database, fed by backup freshness, replica health, and failover configuration — plus a dry-run failover simulation that proves the plan actually works. Honest about the math: RPO is derived from snapshot age, RTO is heuristic from replica count + snapshot size.
-
DR readiness score (0–100)
A single number per database, rolled up by cluster and fleet — driven by backup freshness, replica count, and probe success.
-
RPO from snapshot age
Computed as time since the most recent successful backup / snapshot. Not engine-level transactional RPO.
-
RTO heuristic from topology
~120s when replicas ≥ 2, otherwise size-based formula or 3600s default. Not measured failover; the dry-run simulation surfaces real readiness.
-
Failover simulation (dry-run)
Run the failover plan without touching production; get a pass/fail and the exact steps that would execute.
Right-Sizing Advisor
Find the money you're leaving on the table.
The problem
Everyone "rightsized" during a migration once. Two years later, half the fleet is over-provisioned and a quarter is being throttled — but nobody can prove which pods, so nobody changes anything.
What DBHelm does
Per-pod CPU and memory analysis: requests vs actual usage from the K8s metrics-server, with a concrete recommendation per pod. Pair with the /cost dashboard to translate the waste percentage into a monthly dollar figure using built-in cloud rate cards.
-
Fleet efficiency score
One number for your whole fleet — weighted CPU + memory utilization across all K8s-discovered DBs.
-
CPU & memory waste %
See exactly which pods are overprovisioned, by how much, and which are being throttled.
-
Per-pod recommendations
Exact request/limit values to set — copy straight into your manifest.
-
$ math via /cost dashboard
The advisor returns waste in millicores + bytes; the cost dashboard converts to monthly $ using the AWS/GCP/Azure rate cards.
Compliance Engine
Prove the fleet meets the policy.
The problem
"All our databases use SSL" is an assertion until you can show it. Audit season turns into a three-week scavenger hunt across clusters, consoles, and tribal knowledge.
What DBHelm does
Define policies as code from the seven built-in check types and evaluate against the fleet. Per-DB pass/fail with severity. Honest about scope: policies are session-scoped today, persistent storage + a wider check catalog (encryption-at-rest, audit-log-enabled, framework tags) are on the roadmap.
-
Custom policy builder
Compose rules from the seven built-in check types; tag by severity. Framework tags (SOC2 / HIPAA) on the roadmap.
-
Seven built-in check types
backup_configured, alerting_configured, replica_count, ssl_enabled, max_connections, resource_limits, password_policy. Encryption-at-rest, audit-log-enabled, version-min are on the roadmap.
-
Severity levels
Critical, high, medium, low — with a per-policy and per-database view.
-
Per-DB pass/fail reports
Exportable, timestamped. Persistent policy storage (today: in-memory per session) is on the roadmap.
Upgrade Advisor
Know what's about to be end-of-life.
The problem
Postgres 11 goes EOL. Someone has to know. Someone has to map every 11.x database in the fleet. Someone has to check every app for breaking changes. That someone writes it in a spreadsheet that's out of date two weeks later.
What DBHelm does
A live EOL radar across the fleet. For every database, see current version, EOL date, recommended upgrade path, and a pre-flight check that flags breaking changes and deprecated features before you touch a pod.
-
EOL & nearing-EOL detection
Every supported engine mapped to its official EOL calendar.
-
Upgrade path recommendations
Target version per database, with notes on whether it needs an in-place upgrade or a dump-and-restore.
-
Pre-flight compatibility checks
Breaking changes, deprecated features, driver incompatibilities — surfaced before the maintenance window.
-
Breaking-change catalog
Curated per engine and version — not a link to the release notes.
Capacity Forecasting
"Days until full" — for every database, every day.
The problem
Disk-full alerts fire on a Saturday night. Connection-cap alerts fire during a launch. Capacity problems are predictable; you just have to actually look at the trend.
What DBHelm does
Linear-regression projections for storage, memory, and connections — computed on a 5-minute cache from the K8s metrics-server + engine queries. Every database gets a days-until-full estimate, a growth rate, and an urgency tier. Trend history is session-scoped per process today; persistent history is on the roadmap.
-
Storage, memory & connections
Three dimensions tracked per database, not just disk.
-
Days-until-full per metric
Linear regression on the in-process trend window. You fix the ones under 30 days; you plan the ones under 90.
-
Growth rate per day
Slope of the regression. Useful for capacity planning and cost forecasts.
-
Urgency tiers
Critical / warning / healthy — with a fleet-level summary. Direct-connect DBs need K8s metrics-server access for full forecasts.
Transaction Tracer
The first place to look when it's slow right now.
The problem
"The database is slow" — and now you need to know who's connected, what they're running, how long it's been running, and whether anyone is blocked. Ten different tools, four different engines.
What DBHelm does
A unified live view of active queries, slow queries, and client connections — across PostgreSQL, MySQL, MongoDB, and Redis. Lock contention is full for PG + MySQL (waits and blocked-by graph), aggregate global stats for MongoDB, and not exposed for Redis (single-threaded — there is no lock graph to show). Auto-refreshing, filterable, K8s-discovered DBs only.
-
Active queries & PIDs
Who's connected, what they're running, how long it's been running. All four engines.
-
Slow-query stream
Live feed of queries over a threshold you set per engine. PG / MySQL slow log + Mongo currentOp + Redis SLOWLOG.
-
Lock contention graph (PG + MySQL)
Who's blocking whom — with the blocking statement surfaced. MongoDB shows global lock stats; Redis is single-threaded so there is no lock graph.
-
Per-connection state
Idle, active, waiting — with app name, client IP, and session duration. All four engines.
Why this matters
Zero configuration
Every tool activates automatically when you connect a database. No agents to install. No scrape configs. No PromQL to write. Connect a cluster — all eight are on.
Engine-aware
Every recommendation understands the engine — Galera wsrep, MongoDB oplog, Patroni HA, Raft consensus, Kafka consumer-group lag — not just generic pod CPU and memory.
100% offline
All analysis runs locally on your machine. No telemetry. No cloud roundtrip. No procurement ticket. Your database credentials never leave your laptop.
Connect a cluster.
All seven advisors are on.
DBHelm is a free desktop app — macOS, Windows, and Linux. Install it, point it at a kubeconfig or a database endpoint, and the Intelligence suite works on minute one.