SQL Server 2025 executing request with in SQL connexion is very slow

MT 25 Reputation points

Hello,

I installed SQL 2025 on a new VM to test the installation of my application, which currently runs on SQL 2022. I’m facing an issue with SQL 2025 (fresh installation on a new machine with a new DB): the queries are extremely slow when I use a SQL connection (SA or a new user). However, when I switch to a Windows connection, I get the same response times as with SQL 2022.

For example, I have a C# loop to insert 36K elements into a table via a simple INSERT like this:

INSERT INTO cpvilles(nomvil, copost) VALUES ('ville', 'copost')

With 2025 and SQL connection => 1 hour With SQL 2025 and Windows connection / SQL 2022 with SQL connection => 2 to 5 minutes

Another example: creating 35,000 foreign keys is also extremely slow (simple ALTER TABLE ADD CONSTRAINT).

I’m running exactly the same code between SQL 2022 and SQL 2025: my application hasn’t changed, and when I switch to a Windows connection on SQL 2025, I no longer have any issues.

  1. Viorel 127K Reputation points

    Are you using a single connection object (SqlConnection) in this test?

  2. MT 25 Reputation points

    Nope creating a connexion by request

  3. Viorel 127K Reputation points

    To exclude the C# component, did you investigate the loops in Management Studio using both connection methods:

    INSERT INTO cpvilles(nomvil, copost) VALUES ('ville', 'copost')
go 36000

    Or using a WHILE loop.

  4. MT 25 Reputation points

    In SSMS, I get the same response times on SA or Windows when inserting the 35,000 rows in a loop → 6 seconds. So the issue would likely come from the C# SqlConnection object or from the C# connection string. What is strange is that I don’t really see what would explain why it works very well in SQL 2022 or SQL 2025 in Windows mode, but not with a SQL authentication connection on SQL2025.

    Unless there is some special encryption or something like that happening in “SQL authentication” mode on 2025??

  5. Viorel 127K Reputation points

    It may also be something related to Connection Pooling: https://learn.microsoft.com/en-us/dotnet/framework/data/adonet/connection-pooling (and the sections related to ADO, ODBC).

    Make sure that the C# objects are properly disposed (returned to pool) using the using statement..

Sign in to comment

4 answers

  1. Kaucký Lukáš 0 Reputation points

    In our experiments on SQL Server 2025, adding the startup parameter -T4671 appears to disable the new iterative password hashing mechanism (PBKDF2-based verification).

    Without the trace flag, login times are significantly longer; after enabling -T4671, login performance returns to levels comparable with earlier versions.

    This behavior differs from SQL Server 2022, where trace flag 4671 enabled the iterative hashing feature. It therefore appears that the semantics of TF 4671 have changed in SQL Server 2025.

    One additional observation: SQL logins whose passwords were created while the new hashing mode was active continue to authenticate successfully after switching modes. Authentication does not fail, but it appears to use a slower verification path.

    Resetting the password causes the login to be re-hashed under the currently active mode, which restores expected authentication performance.

    Has anyone seen official documentation confirming this behavior?

    1. Erland Sommarskog 134.7K Reputation points • MVP • Volunteer Moderator

      In my opinion, this behaviour is a serious bug that should be fixed, and I will explain why.

      There are likely to be organisations who decided that they wanted the improved security already with SQL 2022, so they enabled this trace flag in their entire fleet. As they move to SQL 2025, they are likely to keep that trace flag, particularly in cases when they do in-place upgrades. This means that they are all of a sudden unknowingly opting out of the improved security.

      Had this been documented, it would still be bad. There should not be breaking changes that weakens security. Now it is even worse, since it is undocumented, and sites may not find out until it's too late. That is, there has been a breach.

      As for purposely using the trace flag to turn off the improved password protection, it follows from the fact that it is undocumented, that this is also unsupported. (Unless you opened a support case, and Microsoft support actually told you to use this trace flag.) I strongly recommend against using this trace flag. Instead, you should fix your environment so that the improved password checking.

      If you ask Microsoft, they recommend Windows and Entra authentication over SQL authentication all days of the week. I realise that there are situations where none of these are viable alternatives.

      However, even with SQL authentication, you only have a problem if you turning of connection pooling, and you have a pattern where you connect very often to run very short queries. And, I am sorry, such a pattern has "bad practice" stamped all over it, even with connection pooling enabled. If you use this pattern and then disable connection pooling - it's like you want your system to be slow.

    Sign in to comment
  2. Erland Sommarskog 134.7K Reputation points • MVP • Volunteer Moderator

    The underlying reason for this slowdown is likely to be the enhancement described in the top of this blog post: https://techcommunity.microsoft.com/blog/sqlserver/secure-by-default-what%E2%80%99s-new-in-sql-server-2025-security/4424340

    I note that in the topic for CREATE LOGIN it says (my emphasis):

    SQL Server 2025 (17.x) introduces an iterated hash algorithm, RFC2898, also known as a password-based key derivation function (PBKDF). This algorithm still uses SHA-512 but hashes the password multiple times (100,000 iterations), significantly slowing down brute-force attacks. This change enhances password protection in response to evolving security threats and helps customers comply with NIST SP 800-63b guidelines. This security enhancement uses a stronger hashing algorithm, which can slightly increase login time for SQL Authentication logins. The impact is generally lower in environments with connection pooling, but might be more noticeable in scenarios without pooling or where login latency is closely monitored.

    1. MT 25 Reputation points

      And is there no way to disable this new SQL login password hashing system? I’m in a completely closed environment with no external access, so apart from extreme slowness, it brings me no benefit in my case...

    2. Erland Sommarskog 134.7K Reputation points • MVP • Volunteer Moderator

      And is there no way to disable this new SQL login password hashing system?

      It does not seem so.

      I’m in a completely closed environment with no external access, so apart from extreme slowness, it brings me no benefit in my case...

      As I have noted, for this change to really have menacing effect, there is more than one thing you have to do wrong. Nevertheless, the way to go would be to open a support case with Microsoft and clearly state your business case why your code must work the way it does, and why you want an opt-out.

      ...and if even if your system is closed, someone internally could still try a brute-force attack. Which is slowed down considerably with this change.

    Sign in to comment
  3. Erland Sommarskog 134.7K Reputation points • MVP • Volunteer Moderator

    I don't have the time to test this myself right now, but it sounds a bit interesting.

    But only a bit interesting. If you are going to insert 35000 rows, you should do that with with 35000 single-row INSERT statements. That is simply not best practice.

    Instead, insert 500 rows at time, like this:

    INSERT tbl(col1, col2) VALUES(1, 2), (3, 4), ...

    Also, you insist on doing single-row inserts, at least wrap them in BEGIN TRANSACTION and COMMIT TRANSACTION to speed things up.

    As for the case adding foreign-key constraints: 35000 fk constrains are a lot. I have a database with some 8000 tables and we have been quite vigorous with defining FK constraints. Nevertheless there are only 2229 of them in this database.

    1. MT 25 Reputation points

      Hi,

      It’s actually 35,000 constraints in total (foreign keys, default values, etc.).

      As for the inserts, even if it’s bad practice (legacy code dating back to SQL 2008 that hasn’t changed), that doesn’t really explain why, when switching to Windows authentication, I no longer have any issues. If the problem comes from my code (which I can fully accept 🙂), I should experience the same “slowdowns” with Windows authentication, which is not the case.

      Moreover, on SQL Server 2022 everything works without any issues — the same code, with the same database, on the same machine.

    2. MT 25 Reputation points

      I’ve just done a small test with a new .NET Framework form that simply opens a connection without doing anything else.

      With SQL 2025

      SQL authentication connection => 85 ms (SA)

      Windows authentication connection => 2 ms

      With SQL 2022

      SQL authentication connection => 5 ms (SA)

      Windows authentication connection => 3 ms

      So the problem doesn’t seem to come from my code; I’m simply opening an SQL connection in Windows or SQL mode using the SqlConnection object, and the difference between the two is huge.

    3. Erland Sommarskog 134.7K Reputation points • MVP • Volunteer Moderator

      I made a modification of your program, so there was a tight loop of 100 connections. I got these results

      • Windows authentication, SQL 2025 on my local machine: 210 ms.
      • SQL authentication, SQL 2022 on my local machine: 130-155 ms.
      • SQL authentication, SQL 2025 on my local machine: 9025 ms.
      • Azure SQL Database: 16066 ms.

      The last number should tell you why this pattern is bad practice.

      As for the inserts, even if it’s bad practice (legacy code dating back to SQL 2008 that hasn’t changed)

      And do you know what? It was bad practice already in SQL 2008.

      • SQL 2000 introduced support for XML.
      • SQL 2008 introduced table-valued parameters, and I have an article on my web site how to use them: Using Table-Valued Parameters in SQL Server and .NET.
      • I don't know exactly when the SqlBulkCopy class was introduced, but it was probably before 2008.
      • And in SQL 2016 we got JSON.

      All these are alternatives that are a lot more efficient to send down a lot of rows than sending one row at a time.

      As for the ALTER TABLE statements, you can send all constraints for a table in one statement. But more over, opening and closing a connection for each statement is not the best of ideas. If you are running in a loop, keep the connection open.

    4. Fire555 10 Reputation points

      Yes we all can agree it is bad practice, but that doesn't change the fact there is a massive issue when using SQL Auth with SQL 2025. There is clearly an issue that needs to be addressed by MS.

    5. Erland Sommarskog 134.7K Reputation points • MVP • Volunteer Moderator

      Oh, it's even worse than I thought originally. I did not observe that you had connection pooling turned off. There may be reasons to use this if you use application role or EXECUTE AS, but then you should stick to your connections and not reconnect constantly.

      With connection pooling enabled, I get this results for 100 iterations:

      • Windows authentication, SQL 2025 on my local machine: 47 ms.
      • SQL authentication, SQL 2022 on my local machine: 38 ms.
      • SQL authentication, SQL 2025 on my local machine: 129 ms.
      • Azure SQL Database: 217 ms.

      Thus, still slower on SQL 2025 than on SQL 2022. Still faster than connecting to Azure SQL DB. I cannot really see any reason to be concerned.

    Sign in to comment

  4. AI answer

    It seems you are experiencing significant performance differences when using SQL Server 2025 with SQL authentication compared to Windows authentication. Here are a few potential factors to consider:

    1. SET Options: The SQL Server settings (SET options) might differ between your SQL connection and Windows connection. Different SET options can affect how queries are executed. You can check the SET options for both connections and ensure they are consistent.
    2. Parameter Sniffing: If your queries use parameters, SQL Server may optimize the execution plan based on the first set of parameters it encounters. This can lead to suboptimal performance for subsequent executions with different parameters. You may want to consider using OPTION (RECOMPILE) for your queries to force a new execution plan each time.
    3. Execution Context: The execution context can differ between SQL and Windows authentication. Ensure that the user context has the same permissions and roles in both authentication methods, as this can affect query performance.
    4. Network Latency: Although this seems less likely since you're comparing two authentication methods on the same server, ensure that there are no network issues affecting the SQL connection.
    5. Database Compatibility Level: Check if the database compatibility level is set correctly for SQL Server 2025. Sometimes, compatibility levels can affect performance. You can check and change the compatibility level using: 
       SELECT compatibility_level FROM sys.databases WHERE name = 'YourDatabaseName';
 ALTER DATABASE YourDatabaseName SET COMPATIBILITY_LEVEL = 150; -- For SQL Server 2019
    6. I/O Performance: Since you mentioned that the performance is significantly better with Windows authentication, it might be worth investigating if there are any I/O issues or resource contention that could be exacerbated by the SQL connection.

    You may want to run performance diagnostics to identify any bottlenecks or differences in execution plans between the two authentication methods.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.
Sign in to answer

Your answer