Darling/PG vs Datadog DBM: close the in-scope cutover gaps (client) #1606

The client keeps Datadog for APM/trace capture and is replacing only the DBM (database-monitoring) piece with Darling/PG. A code+doc-grounded gap analysis (2026-07-21) confirmed Darling is structurally ahead on database depth (historical Query Store capture, real plans, plan/anomaly/remediation reasoning, in-house data) — DBM uses dm_exec_query_stats only (no Query Store, estimated plans, top-200/host cap). The honest in-scope gaps are a short, mostly-additive list.

Gaps to close (severity for cutover → close-path)

• Managed / HA operation — Medium-High (operationally) — self-hosted single store = SPOF, no in-product replication; they're leaving a managed SaaS. Document a Postgres HA/replication + backup topology. This is the one place DBM's SaaS is genuinely easier — the top real gap.
• Browsable schema explorer (tables/cols/FKs) — Low-Medium — DBM has one; Darling has DDL-change events but no catalog browser. Optional schema-catalog collector + a viewer tab.
• Query-metric retention default < 15 months — CLOSED by the three-tier retention: daily CAGGs are kept indefinitely at full per-query fidelity (Darling: three-tier retention (raw 4d / hourly CAGGs 21d / daily CAGGs kept) #1623), and the availability-gated read-routing (Darling viewer: built-in tabs silently lose history past 4 days - CAGG read-routing only covers Custom Views #1661/Route the viewer's built-in tabs to the retention rollups (#1661) #1664/Darling compose: CAGG routing has no rollup-availability gate — old-window custom-view panels throw 42P01 on plain-PostgreSQL stores #1665, all merged 2026-07) means every reader — built-in tabs, composer, MCP — actually reaches that history. Exceeds DBM's 15 months.
• AG-health metrics — Low-Medium — DBM has explicit sqlserver.ao.*; Darling captures replica role but no dedicated AG-health collector. Add a dm_hadr_* collector (only if they run AGs — real HA telemetry, not advice).
• Dashboard charting primitives — SHIPPED (Reporting layer v1: scatter, dual-axis overlay, brush-zoom (#1606) #1683, 2026-07-26, re-prioritized to crucial): scatter, dual-axis second-measure overlay, and brush-zoom with absolute run windows (windowStart/windowEnd, historical windows first-class for MCP too). Live on DARLING01 with a demo view ("Reporting Layer Demo (Darling/PG vs Datadog DBM: close the in-scope cutover gaps (client) #1606)"). Spin-off finding: Compose: HardRowCap truncation on time series silently keeps the OLDEST slice and says nothing #1687 (row-cap silent truncation).
• Activity sampling 1-min vs DBM's 10s — Low — make query_snapshots cadence configurable / add a fast lane.
• Pre-flight permission audit — being worked as Audit collector/query permission + platform requirements; surface WHY tabs/columns don't populate #1591 (permission/platform requirements catalog + connect-time probe + per-tab "requires X" surfacing).
• Anomaly stats — Low — z-score/ratio only (no MAD/EWMA/changepoint; confidence hardcoded 1.0). Roadmap; the inference layer already beats DBM's threshold-only approach.

Deliberately NOT matching (recorded so it isn't re-proposed)

• Missing-index "recommendations" from sys.dm_db_missing_index_*. DBM surfaces the SQL Server missing-index DMV list, but those recommendations are notoriously low quality — wide covering indexes with every column + dozens of includes, blind to indexes that already exist, and unreliable impact estimates. Surfacing them would lower Darling's advice quality, not add a feature. Darling already does the right thing: per-query execution-plan analysis surfaces missing-index requests in context, and IndexCleanupAnalyzer handles unused/duplicate cleanup — a higher bar than dumping the DMV. Not a gap worth closing; do not build a dm_db_missing_index_* collector for this.

Priority for the cutover: the HA/backup topology doc is the one that actually matters; the rest are additive telemetry/UX polish or run-if-relevant. None touch Darling's core collection depth.

🤖 Filed with Claude Code