// the find
erikdarlingdata/PerformanceMonitor
Free, open-source SQL Server and Postgres performance monitoring. Collectors, real-time alerts, graphical plan viewer, MCP server for AI analysis. Supports SQL 2016-2025, Azure SQL, AWS RDS, Postgres, Aurora Postgres.
A self-hosted monitoring stack for SQL Server and Postgres, shipped as three overlapping editions: a desktop app (Lite) that connects on demand, a headless service (Darling) that collects 24/7 into its own Postgres/TimescaleDB store, and a deprecated SQL-Agent-based Dashboard kept around for existing installs. Built by a well-known SQL Server consultant (Erik Darling) and aimed at DBAs who want SentryOne/Redgate-tier visibility without the per-server licensing or any data leaving their network. The MCP server is the interesting bit — it exposes the same collected metrics as read-only tools so you can point Claude or Cursor at a server and ask it why CPU is pegged.
The collector set is genuinely thorough and well-sourced — 42 named collectors each mapped to a specific DMV or XE session (wait stats, memory grants, plan cache bloat, PVS, AG replica lag), not just a generic 'run some DMV queries' wrapper. The MCP integration is real engineering, not a bolt-on: 89-181 tools depending on edition, read-only, and it redacts statement text that could contain `CREATE LOGIN`/`PASSWORD =` literals from both alerts and MCP answers. No telemetry and credentials go through Windows Credential Manager rather than a config file, which matters for a tool that needs `VIEW SERVER STATE` on production boxes. The Extended Events session lifecycle (per-install IDs, read-only-intent handling on Azure SQL DB, fallback sessions when a shared one is broken) is documented in a level of detail that suggests they actually hit and fixed these edge cases rather than hand-waving them.
Three editions with different storage engines, different MCP tool counts, and a deprecated-but-still-fully-documented fourth option is a lot of surface area for a new user to parse before picking one — the README spends more words explaining which edition to use than explaining any single feature. The viewer is WPF-only, so even the 'headless' Darling edition needs a Windows seat somewhere to actually look at data; Linux support covers collection, not visualization. It's a single-maintainer project tightly coupled to one person's brand (the README leads with social-follow badges and testimonials before any technical content), which is a bus-factor risk for anyone adopting it for production fleets. The amount of documented tribal knowledge around XE session edge cases (HA replica stop semantics, RDS Multi-AZ standby drift, Hyperscale read-intent routing) is reassuring that the author ran into them, but it also signals you will eventually hit one of these yourself and need to read several paragraphs of caveats to understand why a session didn't stop where you expected.