Performance regression von SQL Server 2022 to 2025

Question

Performance regression von SQL Server 2022 to 2025

Patrick Simons2 15

We have the following scenario we could reproduce on a single/same Windows Server 2019:

Microsoft SQL Server 2025 (RTM-CU8) (KB5104822) - 17.0.4075.5 (X64) - Enterprise Developer Edition (64-bit) on Windows Server 2019 Datacenter 10.0 <X64> (Build 17763: )
Microsoft SQL Server 2022 (RTM-CU26) (KB5093420) - 16.0.4265.3 (X64) - Developer Edition (64-bit) on Windows Server 2019 Datacenter 10.0 <X64> (Build 17763: )
an ERP software runs a Crystal Reports (2025) using MSOLEDBSQL 17.8.5 (OLE DB Driver for SQL Server)
The report internally joins tables from 3 databases (using CR EXTERNAL JOIN). I know that this practice isn't smart, but we don't want to change this report. As result Crystal Reports sends a lot of requests to the SQL server.
On SQL 2022 the report takes 7 minutes to complete.
On SQL 2025 around 35 minutes ! This with the same databases on each SQL server instance.

What I tried so far:

on the 3 DBs set the compatibility level to 2022 or ealier - no change
'optimize for ad hoc workloads' to 1 and 'network packet size' to 8192 B - no change
because I saw a ASYNC_NETWORK_IO wait_type, I changed LEGACY_CARDINALITY_ESTIMATION to OFF, or OPTIONAL_PARAMETER_OPTIMIZATION to OFF, or PARAMETER_SNIFFING to OFF, or PARAMETER_SENSITIVE_PLAN_OPTIMIZATION to OFF... - no change
...

So it sounds there is a performance issue (bug) in SQL Server 2025?
Normally if I would set compatibility level to 2022, SQL 2025 should behave like SQL 2022?

Any ideas?

Regards,

Patrick

Patrick Simons2 15 Reputation points

2026-08-25T14:14:36.26+00:00
to answer the AI questions:

2025: Enterprise Developer Edition (64-bit) / 3 / 17.0.4075.5 / RTM / master = 110
2022: Developer Edition (64-bit) / 3 / 16.0.4265.3 / RTM / master = 160

I tested only this report workload which is slower (but there are several others with problems). But the rest of the ERP program runs as expected with SQL 2025.

the execution plans between 2022 and 2025 are identical. The main 2 queries that CR fires are quite simple, like this one as example :
SELECT somefields
FROM Database1.dbo.Table1
WHERE Table1_ID = 'value';
The problem is the high number of queries CR sends...
Deepesh Dhake 840 Reputation points

2026-08-25T14:22:16.5466667+00:00

It looks like it's not the optimizer. Your execution plans are identical between 2022 and 2025, so CE, parameter sniffing, and compat level are all ruled out which is why none of those knobs helped.

The bottleneck is the high volume of connections/round-trips from Crystal firing many tiny queries, not the queries themselves. Your single-row lookups execute in microseconds; the cost is elsewhere.

SQL Server 2025 introduced PBKDF2 password hashing for SQL Authentication, which is a documented, real per-login cost that does not affect Windows Auth. This is a legitimate suspect given your symptoms.
Patrick Simons2 15 Reputation points

2026-08-25T14:27:45.83+00:00

Many thanks, I’ll continue my searches/tests in that PBKDF2 direction. A good tip !
Erland Sommarskog 136.8K Reputation points MVP Volunteer Moderator

2026-08-25T18:05:53.39+00:00

A note about ASYNC_NETWORK_IO: This wait type indicates a problem outside of SQL Server. SQL Server is waiting for the client to pick up the data that SQL Server wants to return. Can be due to slow network, or a poorly written client that does a lot of things with every row it returns.

Given the description of your setup, I would agree with Deepesh that it is a red herring - or why would CR be slower in processing the data from SQL 2025 than SQL 2022?

If CR is using SQL authentication without connection pooling the changed encryption algorithm is surely the reason.

I would definitely look into to replace that EXTERNAL JOIN with something that aligns better with best practice for how to writing modern database applications. (The increased time for the hashing is just one of the problems. Would you put that SQL 2022 instance in the cloud in a data centre at some distance, you would also get hurt.)

2 answers

Your answer

Patrick Simons2 15 Reputation points

2026-08-25T14:14:36.26+00:00

to answer the AI questions:

2025: Enterprise Developer Edition (64-bit) / 3 / 17.0.4075.5 / RTM / master = 110
2022: Developer Edition (64-bit) / 3 / 16.0.4265.3 / RTM / master = 160

I tested only this report workload which is slower (but there are several others with problems). But the rest of the ERP program runs as expected with SQL 2025.

the execution plans between 2022 and 2025 are identical. The main 2 queries that CR fires are quite simple, like this one as example :
SELECT somefields
FROM Database1.dbo.Table1
WHERE Table1_ID = 'value';
The problem is the high number of queries CR sends...
Deepesh Dhake 840 Reputation points

2026-08-25T14:22:16.5466667+00:00

It looks like it's not the optimizer. Your execution plans are identical between 2022 and 2025, so CE, parameter sniffing, and compat level are all ruled out which is why none of those knobs helped.

The bottleneck is the high volume of connections/round-trips from Crystal firing many tiny queries, not the queries themselves. Your single-row lookups execute in microseconds; the cost is elsewhere.

SQL Server 2025 introduced PBKDF2 password hashing for SQL Authentication, which is a documented, real per-login cost that does not affect Windows Auth. This is a legitimate suspect given your symptoms.
Patrick Simons2 15 Reputation points

2026-08-25T14:27:45.83+00:00

Many thanks, I’ll continue my searches/tests in that PBKDF2 direction. A good tip !
Erland Sommarskog 136.8K Reputation points MVP Volunteer Moderator

2026-08-25T18:05:53.39+00:00

A note about ASYNC_NETWORK_IO: This wait type indicates a problem outside of SQL Server. SQL Server is waiting for the client to pick up the data that SQL Server wants to return. Can be due to slow network, or a poorly written client that does a lot of things with every row it returns.

Given the description of your setup, I would agree with Deepesh that it is a red herring - or why would CR be slower in processing the data from SQL 2025 than SQL 2022?

If CR is using SQL authentication without connection pooling the changed encryption algorithm is surely the reason.

I would definitely look into to replace that EXTERNAL JOIN with something that aligns better with best practice for how to writing modern database applications. (The increased time for the hashing is just one of the problems. Would you put that SQL 2022 instance in the cloud in a data centre at some distance, you would also get hurt.)

Answer 1

Your issue is a documented SQL Server 2025 known issue, not an optimizer bug, and not something compatibility level can fix.

Cause: SQL Server 2025 changed the default password hashing for SQL Authentication to PBKDF2. This makes each SQL-login connection much slower and more CPU-intensive - roughly 80ms per connect versus about 4ms with Windows auth in one tester's measurements. Windows Authentication is unaffected. Your Crystal Reports EXTERNAL JOIN across 3 databases opens a flood of connections, so if it's using a SQL login without effective pooling, that per-login cost stacks up into your 7 min --> 35 min blowup. The cost is in login, not query execution, which is why compat level, the CE/parameter/PSP knobs, and packet size all did nothing. The ASYNC_NETWORK_IO wait was a red herring.

Fixes, best first:

Enable connection pooling. The effect is minimal in pooled environments, since PBKDF2 is paid once per pooled connection instead of per request.

Use Windows/integrated auth for the report if the ERP allows which avoids PBKDF2 entirely.

Trace flag 4671 (last resort) in 2025 it disables the PBKDF2 mechanism, but existing SQL logins keep using the slow path until their passwords are reset/re-hashed, so you must change the affected login's passwords for it to take effect

Answer 2

Setting the database compatibility level to an earlier version does not guarantee that SQL Server 2025 will behave the same as SQL Server 2022. The documented guidance is to avoid attributing a regression to one factor alone when the SQL Server version also changed, because version changes can independently affect optimizer behavior and plan selection.

For this case, the fastest grounded path is:

Verify the exact version/edition and DB compatibility on both instances Run:

   SELECT
       SERVERPROPERTY('Edition') AS edition,
       SERVERPROPERTY('EngineEdition') AS engine_edition,
       SERVERPROPERTY('ProductVersion') AS product_version,
       SERVERPROPERTY('ProductLevel') AS product_level;
   
   SELECT
       name,
       compatibility_level
   FROM sys.databases
   WHERE name = DB_NAME();

Since both environments are Developer/Enterprise-family editions, this does not look like a lower-edition regression.

Determine whether all queries are slower or only this report workload The documented first step is to decide whether:
- the entire application is slower,
- all databases are affected,
- only specific reports/queries are affected,
- the slowdown appears for all users or only some,
- it reproduces with one session or only under concurrency.
Based on the description, this currently looks like specific report/query regression, so plan comparison is the next priority.
Compare the execution plans before and after the upgrade Use actual execution plans for the same statement before and after the move. Before comparing, make sure:
- it is the same query or statement,
- parameter values are comparable,
- data volume is comparable,
- database compatibility level is comparable,
- relevant configuration settings are comparable.
In SSMS:
- open the pre-upgrade .sqlplan
- right-click blank plan area → Compare Showplan
- select the SQL 2025 plan
- inspect differences in the dual Properties pane and Showplan Analysis
This is the documented way to confirm whether the regression is plan-related instead of assuming a product bug.
Check whether SQL Server 2025 login latency is part of the total runtime There is a documented SQL Server 2025 known issue mentioned in Microsoft Q&A: PBKDF2 hashing algorithm can affect login performance. Because Crystal Reports sends many requests, repeated connection or login overhead can amplify elapsed time even when query compatibility is set lower. If the slowdown is concentrated at connection/login phases rather than query operators, this is a strong lead.
If the regression is query-plan related, use Query Store to isolate regressed statements The Q&A guidance for version-upgrade regressions is:
- keep the older compatibility level temporarily,
- enable Query Store,
- identify regressed queries,
- as a short-term mitigation, force the previously good plan.
SSMS also exposes Tasks → Database Upgrade to help with upgrade-related plan regressions.
Do not over-focus on edition-only causes The edition-change troubleshooting article is explicit that edition support alone does not prove the cause, and that plans, runtime statistics, waits, or baseline data must be compared. In this scenario, both instances are not moving to a lower edition, so Enterprise-only feature loss is not the primary explanation.

What the current evidence supports:

No, compatibility level 2022 on SQL Server 2025 does not mean identical behavior to SQL Server 2022.
No, the current evidence does not prove a SQL Server 2025 bug by itself.
The most supported next steps are plan comparison, Query Store regression analysis, and checking for the SQL Server 2025 login-performance known issue because the reporting tool issues many requests.