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

MT 45 Reputation points
2025-12-15T07:24:18.83+00:00

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.

SQL Server Database Engine
Answer accepted by question author
Kaucký Lukáš 80 Reputation points
2026-02-11T16:20:40.1633333+00:00

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?

Was this answer helpful?

5 people found this answer helpful.

3 additional answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Erland Sommarskog 137.6K Reputation points MVP Volunteer Moderator
    2025-12-16T22:19:36.34+00:00

    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.

    Was this answer helpful?

  2. Erland Sommarskog 137.6K Reputation points MVP Volunteer Moderator
    2025-12-15T22:35:08.0866667+00:00

    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.

    Was this answer helpful?

  3. AI answer

    2025-12-15T07:24:37.4566667+00:00

    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.

    Was this answer helpful?

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.