Document SQL Server compatibility level bump

Document dotnet/efcore#38198

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Author: Shay Rojansky

entity-framework/core/what-is-new/ef-core-10.0/breaking-changes.md

@@ -24,6 +24,7 @@ This page documents API and behavior changes that have the potential to break ex
 |:--------------------------------------------------------------------------------------------------------------- | -----------|
 | [EF tools now require framework to be specified for multi-targeted projects](#ef-tools-multi-targeting)         | Medium     |
 | [Application Name is now injected into the connection string](#sqlserver-application-name)                      | Low        |
+| [SQL Server compatibility level now defaults to 160](#sqlserver-compatibility-level-160)                       | Low        |
 | [SQL Server json data type used by default on Azure SQL and compatibility level 170](#sqlserver-json-data-type) | Low        |
 | [Parameterized collections now use multiple parameters by default](#parameterized-collections)                  | Low        |
 | [ExecuteUpdateAsync now accepts a regular, non-expression lambda](#ExecuteUpdateAsync-lambda)                   | Low        |
@@ -96,6 +97,39 @@ When a connection string without an `Application Name` is passed to EF, EF now i
 
 A mitigation is to simply define an `Application Name` in your connection string. Once one is defined, EF does not overwrite it and the original connection string is preserved exactly as-is.
 
+<a name="sqlserver-compatibility-level-160"></a>
+
+### SQL Server compatibility level now defaults to 160
+
+[Tracking Issue #38198](https://github.com/dotnet/efcore/issues/38198)
+
+#### Old behavior
+
+Previously, when using <xref:Microsoft.EntityFrameworkCore.SqlServerDbContextOptionsExtensions.UseSqlServer*> without explicitly configuring a SQL Server compatibility level, EF Core defaulted to compatibility level 150, corresponding to SQL Server 2019.
+
+#### New behavior
+
+Starting with EF Core 10.0, <xref:Microsoft.EntityFrameworkCore.SqlServerDbContextOptionsExtensions.UseSqlServer*> defaults to compatibility level 160, corresponding to SQL Server 2022. This allows EF to generate SQL which uses SQL Server 2022 features by default. For example, some queries now use `LEAST` and `GREATEST`, including translations for `Math.Min`, `Math.Max`, <xref:Microsoft.EntityFrameworkCore.RelationalDbFunctionsExtensions.Least*>, <xref:Microsoft.EntityFrameworkCore.RelationalDbFunctionsExtensions.Greatest*>, and some `Take`/`Skip` patterns.
+
+If your database runs on SQL Server 2019 or older, or is configured with a compatibility level lower than 160, some SQL generated by EF Core may no longer be supported by the database.
+
+#### Why
+
+SQL Server 2022 has been available for several years, and using compatibility level 160 by default allows EF Core to generate simpler and more efficient SQL for newer SQL Server versions.
+
+#### Mitigations
+
+If your database does not support compatibility level 160, configure EF Core to use the compatibility level supported by your database:
+
+```c#
+protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
+{
+    optionsBuilder.UseSqlServer("<connection string>", o => o.UseCompatibilityLevel(150));
+}
+```
+
+For more information, see the [SQL Server compatibility level documentation](xref:core/providers/sql-server/index#compatibility-level).
+
 <a name="sqlserver-json-data-type"></a>
 
 ### SQL Server json data type used by default on Azure SQL and compatibility level 170
@@ -164,7 +198,7 @@ protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
 }
 ```
 
-If you're targeting on-premises SQL Server, the default compatibility level with `UseSqlServer` is currently 150 (SQL Server 2019), so the JSON data type is not used.
+If you're targeting on-premises SQL Server, the default compatibility level with `UseSqlServer` is currently 160 (SQL Server 2022), so the JSON data type is not used.
 
 As an alternative, you can explicitly set the column type on specific properties to be `nvarchar(max)`:
 

entity-framework/core/what-is-new/ef-core-10.0/whatsnew.md

@@ -122,6 +122,23 @@ WHERE JSON_VALUE([b].[Details], '$.Viewers' RETURNING int) > 3
 
 Note that if your EF application already uses JSON via `nvarchar` columns, these columns will be automatically changed to `json` with the first migration. You can opt out of this by manually setting the column type to `nvarchar(max)`, or configuring a compatibility level lower than 170.
 
+<a name="sql-server-compatibility-level-160"></a>
+
+### Default compatibility level changed to SQL Server 2022
+
+When using <xref:Microsoft.EntityFrameworkCore.SqlServerDbContextOptionsExtensions.UseSqlServer*> without explicitly configuring a SQL Server compatibility level, EF Core now defaults to compatibility level 160 (SQL Server 2022), rather than 150 (SQL Server 2019). This enables SQL Server 2022-specific SQL translations by default.
+
+For example, `Math.Min`, `Math.Max`, <xref:Microsoft.EntityFrameworkCore.RelationalDbFunctionsExtensions.Least*>, <xref:Microsoft.EntityFrameworkCore.RelationalDbFunctionsExtensions.Greatest*>, and `Min`/`Max` over inline or primitive collections can now translate to `LEAST` and `GREATEST` by default. EF can also use `LEAST` to simplify some queries with multiple `Take` operators, or with `Skip` and `Take`:
+
+```sql
+SELECT [c].[CustomerID], [c].[ContactName]
+FROM [Customers] AS [c]
+ORDER BY [c].[ContactTitle], [c].[ContactName]
+OFFSET @p ROWS FETCH NEXT LEAST(@p1, @p2) ROWS ONLY
+```
+
+If your database is SQL Server 2019 or older, or has a compatibility level lower than 160, configure EF's SQL Server compatibility level explicitly. For more information, see the [breaking change note](xref:core/what-is-new/ef-core-10.0/breaking-changes#sqlserver-compatibility-level-160) and the [SQL Server provider documentation](xref:core/providers/sql-server/index#compatibility-level).
+
 <a name="default-constraint-names"></a>
 
 ### Custom default constraint names