Planning the next major version

[erikdarlingdata]

I'm considering decommissioning the Full dashboard in favor of the Lite dashboard with two modes:

1. What you're used to, standalone, easy to run and monitor tool
2. The Lite dashboard with a Windows Service that is always running, more like what enterprise monitoring tools do

The reasons for this are generally:

1. Maintaining two code bases is difficult (new features, improvements to plan viewer, bugs, and so on)
2. The schema change upgrade path testing for Full has caused major headaches

Before I do anything, I'd like to know what exactly people care about with regard to the Full dashboard.

See? I care.

[aidelia]

I've choose Always-on collection but I felt a little bit confused with the term because at first I've thought the Always On was a refrence to the SQL Server markenting term and not related to Lite data capture.

[erikdarlingdata]

That's why it says "(runs when I'm not at my desk)" next to it 😃

[lukaszherman]

My current use case is to use the dashboard on an ad hoc basis for deeper investigation when issues arise, rather than in continuous mode.

I also plan to collect data from the Performance Monitor database across all SQL instances and send it to my preferred monitoring/observability platform. This would allow developers to view selected data, such as blocking and Query Store metrics, without needing direct access to the SQL instances.

[ghauan]

There are several reasons why I like the full better (I only use Lite for one Azure DB):

1. We use a jump-box for accessing the sql-servers. The account we log on to the server with, will automatically lose its session every 10 hours, then we need to log on again with password, making the Lite version lose connection.

2. Full seems more...eh full 😎, more features (although I only have used Lite for Azure, so maybe I'm wrong)

3. I don't think we can/are allowed to use the mcp-server (or maybe I don't fully understandhow to), but I have Github copilot in SSMS, and it is useful to ask it to look at the data in the PerformanceMonitor database.

That said, I fully understand that it is difficult to maintain two versions.

[ankursuhagia]

I feel lite version a bit laggy. May be due to parquet files. My suggestion would be to have servers captures data by themselves ( keeping it in json format) and pushes to central database - this can be localdb instances as well. And dashboard shows data from central location. For azure sql db as well this will work as data is can be stored in json in any jump server with one collector service.

Maintaining two code base is definitely a challenge

[erikdarlingdata]

You should totally try implementing that and see what it f it improves things.