Performance Regression Observed on SQL Server 2025 Running on Windows Server 2025

2026-10-07T08:59:45.29+00:00

A reproducible performance degradation is observed when executing an identical SQL workload through SQL Server Management Studio (SSMS) on SQL Server 2025 running on Windows Server 2025.

The workload consists of inserting 200,000 records into a table using repeated INSERT statements. The execution time on SQL Server 2025 + Windows Server 2025 is significantly slower compared to equivalent environments using SQL Server 2022.

The issue is consistently observed on virtual machines hosted in OpenShift, while equivalent virtual machines hosted on Hyper-V complete the workload significantly faster.

Configurations Tested

The following combinations do not demonstrate the same performance issue:

SQL Server 2022 + Windows Server 2022 SQL Server 2022 + Windows Server 2025 SQL Server 2025 + Windows Server 2022

The performance degradation is primarily observed with:

SQL Server 2025 + Windows Server 2025 (OpenShift VM) Test Scenario SQL script executed manually through SSMS. Same SQL script executed across all environments. 200,000 rows inserted into the same table. Same database schema. Same test methodology. Multiple executions performed with consistent results. Performance Results SQL Server 2025 + Windows Server 2025 OpenShift VM Records Inserted: 200,000 Elapsed Time: 249.875 seconds Throughput: 800 rows/second Average Row Insert Time: 1.249 ms Hyper-V VM Records Inserted: 200,000 Elapsed Time: 65.034 seconds Throughput: 3075 rows/second Average Row Insert Time: 0.325 ms Observation

The OpenShift environment requires approximately 3.8 times longer to complete the same workload compared to the Hyper-V environment.

Troubleshooting Performed

The following items have been validated or tested:

Database Compatibility Level: Database compatibility level reviewed. Tested with the expected compatibility(150,160) configuration.No significant improvement observed. Query Execution: Same SQL script executed across environments. SQL Server Configuration: SQL Server configuration reviewed.No configuration differences identified that explain the observed degradation. Authentication :Kerberos and authentication behavior reviewed.No authentication failures observed. No SSPI-related errors observed during workload execution. Encryption:SQL Server Force Encryption setting tested. Tuning off force encryption also didnt give any improvement.Workloads executed with encryption-related settings reviewed. TLS Investigation: TLS-related configuration reviewed.No Schannel warnings or TLS negotiation failures observed.

Workload tested on:

Hyper-V virtual machines
OpenShift virtual machines

Hyper-V environment performs as expected.

Performance degradation is primarily observed on OpenShift-hosted Windows Server 2025 virtual machines running SQL Server 2025.

Application Layer Workload reproduced directly in SSMS. Issue is not dependent on application code. Application layer removed from test scenario. Request for Investigation

We request assistance in determining whether this behavior is related to:

A known SQL Server 2025 performance regression. A known Windows Server 2025 performance regression. An interaction between SQL Server 2025 and Windows Server 2025. A virtualization-related issue specific to OpenShift-hosted Windows Server 2025 virtual machines. Any changes in SQL Server 2025 affecting row-by-row insert workloads.

Please advise on additional diagnostics, traces, ETW captures, PerfMon collections, SQL LogScout data, or dump collection requirements needed for further investigation.

I would also add one more line because it is very important:

The workload slowdown is reproducible directly from SSMS without involving the application layer, indicating that the issue can be reproduced using SQL statements alone.

That single sentence immediately tells Microsoft support that they don't need your product installed to reproduce the issue.

 

SQL Server Database Engine

1 answer

Sort by: Oldest
  1. Erland Sommarskog 138K Reputation points MVP Volunteer Moderator
    2026-10-08T15:41:38.89+00:00

    That's a very bad way of inserting 200000 rows. There are a number of things you can do to improve performance.

    The smallest change you can do in this script is to add BEGIN TRANSACTION before the WHILE statement. In the block that follows IF @i % @BatchSize = 0 you add

    COMMIT TRANSACTION
    BEGIN TRANSACTION
    

    And then you need one final COMMIT TRANSACTION at the end.

    With your current script, SQL Server has to wait for the log to be hardened after each INSERT statement. By adding transactions, it only has to wait after every COMMIT. Although, with too many uncommitted INSERT statements, performance can start to degrade. I think a batch size of 10000 is OK, but reducing it to 1000 may be better.

    Even better is to insert multiple rows in the same INSERT statement. There also tools like BCP, BULK INSERT etc that can be useful if you need to insert many rows. I realise that this script is just a benchmark script, so I don't want to go too deep into suggestions with something that may not work in practice.

    But if your application aims at inserting one row at a time, your developers need to reconsider and adhere to best practice.

    I would not recommend you to open a support case. I may cost you and arm and a leg. If the case would lead to that there is actually a defect in a Microsoft product, you should be refunded, but to be honest, I don't expect this to be the outcome here.

    You may think that you see a degradation only on Windows 2025 + SQL 2025 + OpenShift VM, but you are in fact seeing a degradation on all platforms. Add the BEGIN + COMMIT TRANSACTION that I suggested, and you will see a significant difference in all cases.

    If you want to continue investigating the case, one place I would look in is sys.dm_exec_session_wait_stats. Make sure that you start with a fresh connection, and add this to the end of the script:

    SELECT * FROM sys.dm_exec_session_wait_stats WHERE session_id = @@spid ORDER BY wait_time_ms DESC
    

    This will give you an idea of what SQL Server has been waiting for. For reference, this is the result when I ran your script (without transactions added) on my SQL 2025 instance on my desktop computer at home (no VM):

    User's image

    Another good place to check is sys.dm_virtual_io_file_stats, collect it before and after running the script and compute the deltas. This will give you how long time SQL Server has been waiting for the I/O operation to complete. Thus, it includes time to process the I/O in the OS, the hypervisor, the guest OS and the I/O subsystem.

    Tracking down the exact cause can be hard. You may think that you have found a certain software combo to be decisive, but it can in fact be the case that these VM have their disks configured differently.

    And this is also an important reason why this pattern by processing one row at a time - you become more sensitive for small delays that occur with each operation. By adhering to best practice, these configuration differences may not matter at all.

    Was this answer helpful?

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.