Core component of SQL Server for storing, processing, and securing data
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):
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.