Azure SQL Database compatibility level 140 to 150 transition and cardinality estimator behavior
0 reputation · 16 Aug 2022, 00:42 UTC
0 reputation · 16 Aug 2022, 00:42 UTC
Updating the database compatibility level from 140 to 150 in Azure SQL Database triggers a shift from the legacy cardinality estimator (CE) to the new model. This change affects how the engine calculates estimated row counts for queries involving filtered aggregates and parameter-sensitive predicates.
A primary concern during this transition is the interaction between the plan cache and the new CE logic. Because compatibility levels are database-scoped, the transition applies to all schemas simultaneously. There is uncertainty regarding how cached plans generated under level 140 behave when the database is promoted to level 150, particularly when automatic tuning features like Intelligent Indexing are active.
28775 reputation · 16 Aug 2022, 03:56 UTC
Increasing the compatibility level from 140 to 150 in Azure SQL Database invalidates existing cached query plans. The engine does not continue to reuse plans generated under level 140; instead, it triggers a recompilation of queries as they are executed under the new level. This ensures that the optimizer can apply the SQL Server 2019 Cardinality Estimator (CE) and Intelligent Query Processing (IQP) features immediately.
Because the compatibility level is a database-scoped setting, the change acts as a global signal to the engine that the rules for plan generation have changed. You do not need to manually clear the cache (e.g., using DBCC FREEPROCCACHE) to ensure the new CE model is applied, as the version mismatch between the cached plan and the current database level naturally triggers a recompile.
While the invalidation is automatic, the transition typically introduces two primary risks:
ALTER DATABASE [YourDatabaseName] SET COMPATIBILITY_LEVEL = 150;
SELECT ... OPTION (USE HINT('FORCE_LEGACY_CARDINALITY_ESTIMATION'));
To provide a more tailored recommendation regarding plan stability, please specify if you are currently using Automatic Tuning (Force Last Good Plan), as this can automate the mitigation of the regressions described above.
Use comments to ask for clarification. Post a solution as an answer.
28,775 reputation · 16 Aug 2022, 10:44 UTC
Each cached query plan stores the compatibility_level and cardinality_estimation_model_version values that were active when the plan was compiled. When the database compatibility level is altered from 140 to 150, the execution engine compares these stored values to the current database settings. If they differ, the plan is considered out‑of‑date and is automatically marked for recompilation on next use. This mechanism ensures that the new SQL Server 2019 Cardinality Estimator (CE 150) is applied without requiring a manual cache flush, and it operates independently for each database, leaving plans in other databases untouched.
You can verify this behavior by querying sys.dm_exec_plan_attributes for a plan handle and looking for the compatibility_level and cardinality_estimation_model_version attributes before and after the level change.