Erik Darling wants configurable wait stat collections on a database level built into SQL Server:
I’m hoping that a feature like this could solve some intermediate problems that Query Store doesn’t.
Namely, being lower overhead, not collecting any PII, and not taking up a lot of disk space — after all, we’re not storing any massive stored proc text or query plans, here, just snapshots of wait stats.
This will help even if you’re already logging wait stats on your own. You still don’t have a clear picture of which database the problem is coming from. If you’ve got a server with lots of databases on it, figuring that out can be tough.
Understanding what waits (and perhaps bottlenecks) a single database is experiencing can also help admins figure out what kind of instance size they’d need as part of a migration, too.
It’s an interesting approach. If you agree with Erik, go vote.