# erikdarlingdata/PerformanceMonitor: SQL Server and Postgres monitoring without per-server fees

> A free MIT-licensed monitoring stack for SQL Server 2016-2025, Azure SQL, AWS RDS and Postgres, shipped as a desktop app, a headless Windows service, and a deprecated in-server dashboard. Here is what each edition actually does, and where the documentation runs out.

**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.

- Repository: https://github.com/erikdarlingdata/PerformanceMonitor
- Website: https://erikdarling.com/free-sql-server-performance-monitoring/
- Stars: 509 · Forks: 97
- Language: C#
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/erikdarlingdata-performancemonitor

## The problem: per-server monitoring licences and agents you cannot install

Commercial SQL Server monitoring is priced per server per year, and the install usually wants an agent, a repository database, or both on the machine you are trying to observe. That is fine when you own the box. It is not fine for Azure SQL Database, where there is no host to install onto, or for a locked-down production server where a change request takes three weeks.

PerformanceMonitor takes the other position. The README describes it as "Free, open-source monitoring that replaces the tools charging you thousands per server per year" and states that nothing phones home, with data staying on your server and your machine. The target reader is a DBA, a consultant, or an infrastructure engineer responsible for several SQL Server or Postgres instances, including managed ones. The support matrix in the README lists SQL Server 2016 through 2025, Azure SQL Managed Instance, AWS RDS for SQL Server, Azure SQL Database, Postgres and Aurora Postgres. The primary language is C# and the licence is MIT.

## Three editions, one monitoring brain, and a deprecation you should not skip

The README is explicit that the collectors, alert engine, plan analysis and MCP tools are shared across all three editions at the library level. What differs is where collection runs and where data lands.

Lite is the flagship. It is a single desktop app that monitors remotely and on demand, installs nothing on the target server, and stores data locally in DuckDB plus Parquet. Darling is headless: a Windows service that collects continuously into a bundled PostgreSQL with TimescaleDB, with a detached viewer that reads the store from any seat. The Dashboard edition installs a PerformanceMonitor database on the target SQL Server, uses SQL Agent collectors, and needs a separate viewer app.

The Dashboard is deprecated. Existing installs keep working and stay on bug-fix support, but the README states 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. Both remain buildable from the repository, and their documentation lives under deprecated/Dashboard/README.md and deprecated/Installer/README.md. If you find a tutorial describing the in-server database approach, check its date before following it.

The permission model follows the same split. Lite and Darling both need VIEW SERVER STATE on the targets; the Dashboard additionally needs SQL Agent. That single grant is the whole footprint for the two current editions, which is the strongest argument for the design.

## Installing Lite and collecting your first wait stats

The README points new users at the Lite release page and says one download gets data flowing in under 5 minutes, with nothing installed on the server. The repository does not document a command-line installer for Lite, so installation is the desktop app from the latest release rather than a package manager command. What you need before you start is a login with VIEW SERVER STATE on the instance you intend to watch.

The repository ships a build script for the Lite app, so building from source is a supported path if you would rather not run a release binary:

```bash
build-lite.cmd
```

Running that script from the repository root produces the Lite build. The README notes that all release binaries are digitally signed via SignPath, so release downloads should not trigger Windows SmartScreen warnings; a locally built binary will not carry that signature.

Once the app is open, the workflow the README describes is to point it at a server and let the collectors run on their configurable schedules. Wait stats, query performance, blocking chains, deadlock graphs, memory grants, file I/O, tempdb and perfmon counters are all listed as collectors, and the README states that query text and execution plan collection can be disabled per collector for sensitive environments. That per-collector switch matters more than it sounds: it is the difference between a monitoring tool you can run in a regulated environment and one you cannot. Set it before the first collection run, not after, because the README does not describe a way to purge already-captured query text.

From there you land on the NOC-style overview with green, yellow and red health cards, auto-refresh and configurable time ranges. Alerts for blocking, deadlocks and high CPU arrive as system tray notifications, styled HTML email with full XML attachments, and webhooks.

## The plan viewer and the MCP server are the parts that are hard to replace

Two features in the README are not commodity. The first is the graphical plan viewer: native ShowPlan rendering, a 30-rule PlanAnalyzer, operator-level cost breakdown, and a standalone mode that opens .sqlplan files without a server connection. Standalone mode is the interesting one. It means you can hand a plan file to a colleague, or open one from a ticket, with no instance, no credentials and no VPN. Most plan viewers are welded to a live connection.

The second is the built-in MCP server, which the README describes as enabling AI-powered analysis with tools like Claude. The repository carries the Model Context Protocol in its topic list and an llms.txt file at the root, alongside PerformanceMonitor.Analysis and PerformanceMonitor.PlanAnalysis projects. If your team already uses an MCP-capable assistant, this is a way to let it query your own monitoring data instead of pasting screenshots into a chat window. It is also the feature with the least documentation in the README: there is no configuration example, no list of exposed tools, and no description of what the server sends outward. Treat the MCP server as something to evaluate in a lab before it touches production data.

The Recommendations tab is a third differentiator, and the one I would be most careful with. The README describes a recommendations engine that surfaces prioritized findings from your own monitoring data with the reasoning behind each one, and can apply selected fixes directly. Destructive changes, such as enabling Read Committed Snapshot Isolation, are gated behind an informed-consent dial. That gating is the right instinct, but a tool that can change server configuration from a desktop app deserves a read of its own before you point it at anything that matters.

## Where this is the wrong tool

PerformanceMonitor is not a fleet-wide observability platform. There is no mention of high availability for the monitoring stack itself, no clustering story for the Darling service, and no documented retention or purge policy for the Lite DuckDB and Parquet files. If your requirement is a long-term metrics warehouse with cross-team dashboards and an on-call rotation built on top of it, the Lite edition's local files will not satisfy it, and Darling gives you a single Windows service and a bundled PostgreSQL rather than a horizontally scaled collector fleet.

The permission requirement is a real boundary too. Without VIEW SERVER STATE on a target, there is nothing to collect, and the README does not describe a lower-privilege mode. On Azure SQL Database the README points you at the Lite and Darling editions specifically, which makes sense given that neither installs on the server, but the documentation does not spell out which collectors behave differently on that platform.

Finally, the repository layout is a warning about the project's history. There is a deprecated/ directory, a separate install/ directory, an upgrades/ directory, an active Lite/ project and a PerformanceMonitor.sln that spans many projects. This is a codebase mid-migration from an in-server design to a client-side one. That is a reasonable direction, but it means older blog posts, older videos and older issues will describe an architecture that no longer matches the recommended path.

## How it compares to the in-server monitoring you may already run

The closest alternative in approach is the classic in-server collector: a database on the monitored instance, SQL Agent jobs writing snapshots into it, and a separate viewer application on a workstation. That is exactly what the deprecated Dashboard edition was, and it is what many homegrown monitoring setups look like. The difference is architectural rather than cosmetic. In-server collection puts the monitoring load and the monitoring data on the same machine that is already under stress, and it makes the repository database part of your backup and disaster-recovery scope. PerformanceMonitor's current editions move both off the target: Lite to local DuckDB and Parquet, Darling to a bundled PostgreSQL with TimescaleDB on a machine you choose.

The trade-off is that you now have a second thing to run. Darling needs a Windows service host and a PostgreSQL instance, which is more operational surface than a couple of Agent jobs. Lite avoids that entirely but only collects while the app is open and pointed at a server, which is fine for triage and wrong for capturing the deadlock that happens at 03:00. The README's own framing reflects this: it recommends Lite for quick triage, Azure SQL Database, locked-down servers, consultants and firefighting, and Darling for always-on monitoring of many servers from one service.

If you are comparing against a commercial platform, the honest difference is support and scope, not capability. You get a plan viewer, alerting and collectors under MIT, and you give up vendor escalation and whatever managed retention the commercial product bundles. That is a fair trade for a DBA with the time to read the docs, and a poor one for a team with no SQL Server expertise at all.

## Maintenance, releases and what MIT actually gets you

The last push to the default branch was on 2026-09-10, and the repository is not archived. Releases are frequent: v3.5.0 on 2026-08-19, v3.6.0 on 2026-08-27, and a nightly build tagged 3.6.0-nightly.20260910 on 2026-09-10. Nightly builds are published alongside stable ones, so pin to a versioned release rather than tracking nightly unless you are deliberately testing.

Upgrade cost is low on the Lite side, because a single desktop app has no server-side schema to migrate. Darling carries more: it bundles PostgreSQL and TimescaleDB, and the repository has an upgrades/ directory, which suggests schema changes ship with releases. The README does not document a rollback procedure for a Darling upgrade, so back up the store before applying one.

The licence is MIT, which in practice means you can use this commercially, modify it, and redistribute it, with the usual requirement to preserve the copyright and licence notice. The repository also carries a THIRD_PARTY_NOTICES.md file, which is where the bundled components' own terms are recorded; if you redistribute a build, that file is the one to read. None of this is legal advice, and if you are embedding the tool in a product you ship, have counsel review the notices rather than relying on the MIT label alone.

## Conclusion

Adopt the Lite edition if you are a DBA or consultant who needs triage on servers you cannot install software onto, and Darling if you need one Windows service collecting 24/7 from many instances into a bundled PostgreSQL and TimescaleDB store. Do not adopt the Dashboard edition for new work: it is deprecated, and as of v3.3.0 the Dashboard and its CLI installer are no longer included in release assets. Before committing, verify that your login has VIEW SERVER STATE on every target, confirm which collector schedules you will disable for sensitive environments, and decide where the Lite DuckDB and Parquet files will live, because the README does not document a retention or purge policy for them.

## FAQ

### What is erikdarlingdata/PerformanceMonitor?

It is a free, MIT-licensed monitoring tool for SQL Server and Postgres, written in C#. The README describes specialized collectors, real-time alerts, a graphical plan viewer, and a built-in MCP server for AI analysis, with data staying on your own server and machine.

### How do I install PerformanceMonitor on Windows?

The README points new users at the Lite release page and says one download gets data flowing in under 5 minutes with nothing installed on the server. There is no documented command-line installer for Lite; building from source uses build-lite.cmd from the repository root.

### What permissions does PerformanceMonitor need on SQL Server?

The README's editions table lists VIEW SERVER STATE for both Lite and Darling, and VIEW SERVER STATE plus SQL Agent for the deprecated Dashboard edition. No lower-privilege mode is documented.

### Does PerformanceMonitor work with Azure SQL Database?

Yes. The README lists Azure SQL Database under the supported platforms and names the Lite and Darling editions for it, which fits the fact that neither installs anything on the target server.

### Is the Dashboard edition still supported?

It is deprecated. Existing installs keep working on bug-fix support, but 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 should use Lite or Darling.

## Sources

- [erikdarlingdata/PerformanceMonitor on GitHub](https://github.com/erikdarlingdata/PerformanceMonitor)
- [License: MIT](https://github.com/erikdarlingdata/PerformanceMonitor/blob/main/LICENSE)
- [Project website](https://erikdarling.com/free-sql-server-performance-monitoring/)
- [README](https://github.com/erikdarlingdata/PerformanceMonitor/blob/main/README.md)
- [Releases](https://github.com/erikdarlingdata/PerformanceMonitor/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/erikdarlingdata-performancemonitor