Performance Monitor: Free SQL Server Monitoring That Doesn’t Phone Home

I spend a lot of time on this blog talking about tools. Some of them are good. Some of them are overhyped on LinkedIn. This one is neither overhyped nor underpowered. It’s the real deal.

Performance Monitor is a free, open-source SQL Server monitoring tool built by Erik Darling of Darling Data. MIT-licensed. No telemetry. No cloud dependency. Your data stays on your server and your machine. And it replaces tools that charge thousands of dollars per server per year.

I’ve known Erik for years. He’s one of the sharpest SQL Server performance specialists working today, and his video training is genuinely top-notch – well crafted, practical, and useful for any working SQL Server DBA. But friendship doesn’t earn a feature review. The code does. I went through the repository and here’s what I found.

Two Editions, Different Philosophies

Performance Monitor ships in two editions that solve the same problem from different angles.

The Full Edition installs a dedicated PerformanceMonitor database on your SQL Server with 32 T-SQL collector stored procedures, three SQL Agent jobs, and two Extended Events sessions. A separate WPF dashboard connects to the monitoring database and displays everything with charts, grids, and alerts. This is your 24/7 production monitoring setup.

The Lite Edition installs nothing on the target server. It’s a single desktop application that queries your SQL Server remotely using VIEW SERVER STATE, stores everything locally in DuckDB with Parquet archival, and displays the dashboard in the same app. This is your consultant toolkit, your Azure SQL Database monitor, your “I can’t install anything on this server” solution.

Both editions include a graphical execution plan viewer with a 30-rule plan analyzer, real-time alerting, and an embedded MCP server for AI-assisted analysis.

What It Actually Collects

The Full Edition runs 32 collectors. Not 32 vague “metrics.” 32 specific, well-scoped data collection procedures, each with its own frequency, retention policy, and error isolation. Here are some highlights:

• Wait stats (delta-based, every minute) – not cumulative snapshots, actual deltas since last collection
• Query stats and procedure stats (delta-based, every minute) – with optional query text and execution plan capture
• Blocking and deadlocks – captured via Extended Events ring buffers, then parsed into structured tables by a separate processing collector
• Memory grants, memory clerks, plan cache bloat – the memory monitoring alone would justify the install
• File I/O stats (delta-based) – per-database, per-file latency trends
• Default trace events – auto-growth, DDL changes, configuration changes
• Query Store integration – per-database collection from Query Store DMVs
• Latch and spinlock stats – for those deep-dive performance investigations
• Server configuration change detection – captures sys.configurations snapshots and flags changes
• Running jobs duration analysis – compares current job runtime against average and p95 historical duration

Every collector runs inside its own BEGIN TRY/BEGIN CATCH, so a failure in one never stops the rest of the cycle. The master dispatcher uses a cursor over a schedule table, checks which collectors are due, and dispatches them. If your server restarts, it detects that by comparing sqlserver_start_time against the last recorded value and captures a fresh server properties snapshot.

The Architecture Is Production-Grade

Three things stood out when reading the code.

Self-healing design. The config.ensure_config_tables procedure runs at the start of every collection cycle. If someone accidentally drops a config table, it gets recreated automatically. Individual collectors call config.ensure_collection_table if their target table is missing. A hung-job watchdog runs every 5 minutes and kills the collection job if it gets stuck.

Resume intelligence. When collection resumes after an outage or an “Off” preset period, the tool clamps the lookback window to prevent a data explosion. Without this (learned the hard way, per issue #892), the query_stats collector would sweep all historical DMV data on resume, potentially blowing out tempdb.

Platform awareness. The installer detects Azure SQL Managed Instance (Engine Edition 8) and AWS RDS (presence of rdsadmin database) and automatically disables collectors that can’t run on those platforms. No manual configuration, no cryptic error messages – it just adapts.

The T-SQL Is Excellent

I read through a significant portion of the install scripts, and the code quality is consistently high. Every procedure uses the idempotent CREATE/ALTER pattern (safe to re-run). Every file starts with the same SET options block. COUNT_BIG() instead of COUNT(*). Named parameters on system procedure calls. Block comments only. Delta calculations for cumulative DMVs. COMPRESS()/DECOMPRESS() for large text columns.

The deduplication pattern in the default trace collector is particularly clean – an anti-join with a one-hour time window to prevent re-collecting events without doing a full-table scan.

Erik’s style guide is documented in CONTRIBUTING.md and consistently applied. You don’t have to agree with every choice (the column_name = expression alias style is not the only way to alias columns in T-SQL but it is the best way), but the consistency is what matters.

Alerting That Respects Your Time

Eight alert types with configurable thresholds, delivered via system tray notifications, SMTP email (with styled HTML and XML attachments), or webhooks for integration with Slack, Teams, or a wide variety of enterprise monitoring tools. Mute rules support field-level matching with optional expiration. Alerts auto-clear when conditions resolve.

The poison wait type monitoring is a nice touch: THREADPOOL, RESOURCE_SEMAPHORE, and RESOURCE_SEMAPHORE_QUERY_COMPILE are explicitly monitored as indicators of severe resource starvation. These are the waits that mean “something is very wrong right now,” and getting an alert for them is worth the SMTP configuration effort.

AI Integration That Makes Sense

Both editions embed an MCP server (localhost only, disabled by default) exposing 52-63 read-only tools to LLM clients like Claude Code, GitHub Copilot, Cursor, or any other MCP-compatible tool. This isn’t a gimmick. Having an LLM that can query your wait stats history, blocking chains, and query performance trends through a structured API is a genuinely useful workflow for diagnosing problems.

Setup is straightforward – for Claude Code it’s one claude mcp add command; other tools have similar configuration. The tools are read-only. Nothing phones home.

What You Should Know Before Installing

• Windows only. The dashboard and Lite edition are WPF applications. No Linux or macOS support.
• Full Edition requires SQL Agent – which means no Azure SQL Database (use Lite for that).
• Storage requirements are real. The Full Edition uses 5-10 GB/week with default 30-day retention. Plan your disk accordingly.
• The FinOps Index Analysis feature has a documented issue (#915) where missing database-level permissions can trigger an infinite recompile loop in SQL Server 2016 SP3 through 2025 CU4. This is a SQL Server engine bug, not a Performance Monitor bug, but PM exposes it. The fix (per-database grants) is documented in the README.
• sp_WhoIsActive is GPLv3. It’s bundled as an optional dependency and called as an external tool. Organizations with strict GPL policies can skip it during installation.

The License Is Exactly What It Says

MIT. The full source is on GitHub. Every feature – collectors, plan analyzer, MCP server, FinOps, alerting – is in the free version. Commercial support tiers ($500/year and $2,500/year) are available but purely for service agreements. The software is identical regardless.

No open-core bait-and-switch. No “community edition” that’s missing the features you actually need. No crypto-currency token marketing. In short, it’s what you wish every application is; great at what it does, inexpensive, and the source code is available.

The Companion Tool

Performance Monitor tells you which queries are hurting your server. Erik’s other tool, Performance Studio, tells you why. I’ve written a separate review of Performance Studio that covers its execution plan analysis capabilities. The two tools share the same 30-rule plan analyzer engine and complement each other naturally: Monitor identifies the problem queries, Studio explains what’s wrong with their execution plans.

Should You Use It?

If you’re a SQL Server DBA running production workloads and you’re not already using an enterprise monitoring tool, this is worth your time. If you are using an enterprise monitoring tool and your license renewal is coming up, this is worth evaluating.

The code is solid. The release cadence is intense (11 minor versions in roughly 3 months, with ~130 issues processed). The author is a recognized expert in the field. And the price is right.

GitHub: erikdarlingdata/PerformanceMonitor | erikdarling.com

Have questions about SQL Server monitoring? Let me know on Bluesky or LinkedIn.