PerformanceMonitor: a free SQL Server monitoring stack with three deployment shapes

The gap PerformanceMonitor is aimed at

Commercial SQL Server monitoring is priced per server per year, and the README opens by framing this project as a replacement for tools in that bracket. The audience it names is specific: consultants, DBAs triaging locked-down servers, and anyone working with Azure SQL Database where you cannot install an agent. That constraint drives most of the design. The Lite edition installs nothing on the monitored server and stores its data locally in DuckDB and Parquet files. The README also states that nothing phones home and that data stays on your server and your machine, which matters if your monitoring host is not allowed to reach a vendor endpoint. The project covers SQL Server 2016 through 2025, Azure SQL Managed Instance, AWS RDS for SQL Server, Azure SQL Database, Postgres, and Aurora Postgres, so the same tool is meant to sit in front of more than one engine family.

Three editions, three very different footprints

The edition table is the most useful part of the README because it answers the question people usually get wrong. Lite is a single desktop app that monitors remotely and on demand, storing locally in DuckDB and Parquet. Darling is a Windows service that collects around the clock into a bundled PostgreSQL with TimescaleDB, with a detached viewer reading from that central store. The third, Dashboard, installs a database named PerformanceMonitor on the target SQL Server and relies on SQL Agent, with a separate viewer application. Only Darling and Dashboard require a place to run something beyond your workstation; Lite requires neither. The README says the monitoring brain (collectors, alert engine, plan analysis, MCP tools) is shared across all three at the library level, so the differences are about collection topology and storage rather than feature parity at the analysis layer. If you are choosing today, the README's own instruction is to start with Lite.

Collectors, alerts, and what the plan viewer actually renders

Collection is organised as specialised collectors on configurable schedules. The README lists wait stats, query performance, blocking chains, deadlock graphs, memory grants, file I/O, tempdb, perfmon counters, and FinOps or capacity collectors. Two of those can be turned off per collector: query text and execution plan collection, which is the setting to reach for in environments where statement text is sensitive. Alerts fire in real time for blocking, deadlocks, and high CPU, delivered through system tray notifications, styled HTML email with full XML attachments, and webhooks. The plan viewer renders ShowPlan natively and includes a 30-rule PlanAnalyzer with operator-level cost breakdown. There is also a standalone mode for opening a .sqlplan file with no server connection, which is the feature that makes the tool usable when someone emails you a plan from a system you cannot reach.

Getting it running, and the one permission that matters

The README's quick path is a single download from the latest release. Nothing is installed on the monitored server for Lite, and the README claims data flowing in under five minutes. The permission required is VIEW SERVER STATE; Darling additionally needs a place to run the service, and the Dashboard edition needs SQL Agent. Release binaries are described as digitally signed via SignPath, which the README ties to the absence of Windows SmartScreen warnings. One practical caveat sits in the release history rather than the prose: alongside tagged versions such as v3.6.0 and v3.5.0, there is a nightly build channel, and the most recent entry at the time of writing is 3.6.0-nightly.20260910. If you pin to tagged releases you avoid that channel, but you also wait for fixes that may already exist in nightly.

The MCP server and the Recommendations tab

Two features distinguish this from older free monitoring scripts. The first is a built-in MCP server, described as supporting AI-powered analysis with tools like Claude. The README does not document the tool surface or transport in the material available here, so treat the exact integration contract as something to confirm from the repository rather than assume. The second is a Recommendations tab that surfaces prioritised findings derived from your own collected monitoring data, along with the reasoning behind each one. The README labels this advise-and-act and states that it can apply selected fixes directly, with destructive changes such as enabling Read Committed Snapshot Isolation gated behind an informed-consent dialog. That is a meaningful line to draw, and it is also the feature most likely to require a conversation with whoever owns change control at your organisation.

Where this is the wrong tool

Lite collects on demand from a desktop application. If your requirement is continuous capture of an intermittent problem that happens at 03:00 while your laptop is closed, Lite is the wrong edition and Darling is the right one, at the cost of running a Windows service and maintaining a PostgreSQL with TimescaleDB instance. The central store is a second system to patch and back up, and the README does not describe its sizing or retention behaviour in the material available. The Dashboard edition is a harder stop: the README states it is deprecated, that existing installs remain on bug-fix support, and that as of v3.3.0 the Dashboard and its CLI installer are no longer included in release assets, with the last shipped builds in the v3.2.0 release. New deployments are told to use Lite or Darling. Anyone with an existing Dashboard install is therefore on a path with a defined end and no documented migration procedure in this README. There is also an unquantified trust question in the Recommendations engine: a tool that can apply schema-affecting changes to production is a different risk category from one that only reads.

How it compares with building on the First Responder Kit

The obvious alternative for a SQL Server shop is the collection of stored procedures in the First Responder Kit, which DBAs already run by hand or schedule through SQL Agent. The difference in approach is structural rather than a matter of which queries are better. The First Responder Kit gives you diagnostic scripts you execute and read; it has no persistent store, no alert engine, no graphical plan renderer, and no MCP server. PerformanceMonitor wraps the same category of diagnostic data in scheduled collectors, a storage layer (DuckDB and Parquet locally, or PostgreSQL with TimescaleDB centrally), alerting over tray, email, and webhooks, and a desktop interface with health cards and charts. The trade is that you accept a C# application and, in the Darling case, a database you now operate. If your workflow is already a set of scripts and a query window, the First Responder Kit asks nothing new of you. If you want history, alerting, and a plan viewer without paying per server, that is the gap this project is filling.

Licence, maintenance, and what to check before rolling it out

The licence is MIT, which is permissive and places few obligations on how you use or redistribute the code. This is a description of the licence identifier, not legal advice; read the LICENSE file and your own policy if redistribution matters to you. On maintenance, the repository shows a release cadence measured in weeks rather than years, with v3.5.0 and v3.6.0 arriving in August 2026 and a nightly build following in September, and the last push date matches that nightly. That cadence cuts both ways: fixes arrive quickly, and the surface you are running changes often enough that pinning to a tagged release is the safer default for production monitoring. The concrete things to verify before adopting are the ones the README leaves open. Confirm that VIEW SERVER STATE is grantable to your monitoring login on every target, including the Azure SQL Database and AWS RDS cases. Check whether your environment can accept a Windows service plus a PostgreSQL and TimescaleDB instance if you pick Darling. And decide, explicitly, whether the Recommendations tab is allowed to apply changes on your servers, because that setting is the difference between a read-only observer and a tool with write access to production.

Editorial conclusion

Adopt the Lite edition if you are a consultant or a DBA doing triage against servers you cannot install software on, because it needs only VIEW SERVER STATE and keeps its DuckDB and Parquet files on your own machine. Choose Darling instead if you need collection to continue while nobody is watching. Do not start a new deployment on the Dashboard edition; the README states it is deprecated and that its installer and app stopped shipping in release assets as of v3.3.0, with the last builds in the v3.2.0 release. Before you commit, verify two things in your own environment: that the account you will connect with actually holds VIEW SERVER STATE on every target, and whether your organisation permits the Recommendations tab to apply changes, since the README says destructive fixes such as enabling Read Committed Snapshot Isolation sit behind an informed-consent dialog you will have to operate.

Official sources

1. erikdarlingdata/PerformanceMonitor on GitHub
2. License: MIT
3. Project website
4. README
5. Releases