One of the features that benefited most from the insight provided by the telemetry data was Query Store, which was originally released in private preview for Azure SQL Database in early 2015. At the time of the SQL Server release, Azure SQL Database had been in existence for over two years and Microsoft had been capturing telemetry and using that data to understand how features were being used, as well as improve existing features. “Data Driven” was frequently used in Microsoft marketing materials for 2016, but it wasn’t hype it was true. One reason the SQL Server 2016 release was such a solid release was that it was data driven. You should be running the latest version CU for SQL Server 2017 and latest CU for SQL Server 2016 SP2 to get all performance-related improvements Microsoft has implemented specific to Query Store.With an ad-hoc workload there are additional factors to consider when using Query Store. An impact on system performance can be seen with ad-hoc workloads (think Entity Framework, NHibernate), but I still think it’s worth enabling.Is there a “magic number” to use to figure out Query Store performance and the increase in resource use? No, it will depend on the type of workload.Will there be an increase in resource use (CPU, memory)? Yes.The majority of workloads won’t see an impact on system performance.What people are really asking is “Does enabling Query Store affect the performance of my queries?” Where “my queries” are user queries, queries from the application, etc. I get asked this question almost every time I present on a topic related to Query Store.

“What is the performance overhead of enabling Query Store?” Edit: Novem– Updated information about Query Store performance overhead can be found in this post.

Filebeats cpu overhead