Sql Server 2025 Updated Application working Slow

With the amount of information you have shared, we can only give generic answers.

First of all, how did you upgrade? Did you make an in-place upgrade, or did you move to new hardware. In the latter case, the issue may rather lie with the new machine where you have different configuration from the old server.

Have you changed the compatibility level of the database to 170? It is not uncommon to see performance regressions when you upgrade to a new version of SQL Server, and more precisely when you move to a new compatibility level. The reason for these regressions is that there are changes in the optimiser that backfires in your particular case - even if these changes are intended to be improvements in the general case.

A good strategy when moving to a new version of SQL Server is to enable Query Store and stay with the old compatibility level for, say, two weeks. Then you can switch to the new compatibility level. You can now use the Query Store reports in SSMS to find regressed queries. As a short-term solution you can force the good plan from the lower compat level. As a long-term solution, you should analyse the query more closely and see what can be done by adding indexes, query rewrites etc. There is also a tool in SSMS for this; select the Tasks menu in Object Explorer for the database, and you find Database Upgrade at the bottom of the menu.

After upgrading to SQL Server 2025, slow performance can come from general workload issues or from specific 2025-known issues. Use the following checks and mitigations.

1. Check for known SQL Server 2025 issues

• Review the SQL Server 2025 known issues list and verify whether any apply to the environment, especially:
  • PBKDF2 hashing algorithm can affect login performance: This can cause noticeable login latency, which might look like the whole application is slow when it frequently opens new connections.
  • SQL Server might become slow or unresponsive after creating or bringing online a large number of databases: If the instance hosts many databases, worker thread pressure from the “Persisted statistics for readable secondary replicas” feature can slow the whole server.
• If the instance has many databases and you see slowness or unresponsiveness after startup or when bringing databases online, apply the documented workaround:
  • Enable startup trace flag 15608 (per the Persisted statistics feature guidance) and restart SQL Server so that the per-database background worker threads are not created.

References for these issues and mitigations are in the SQL Server 2025 known issues article.

2. Verify whether the slowdown is in SQL Server or in the application layer
3. Take representative slow queries from the application and run them directly in SSMS against the same SQL Server 2025 instance.
4. Compare performance:
   • If queries are fast in SSMS but slow in the application, the problem is likely in the application tier (ORM behavior, connection handling, network, or client drivers).
   • If queries are slow in both SSMS and the application, continue with SQL Server/OS troubleshooting below.
5. Check OS-level performance on the SQL Server host

On the server running SQL Server 2025:

• Confirm the OS is responsive (RDP, file shares, UI responsiveness). If the whole OS is slow, use Task Manager, Resource Monitor, or Perfmon to check:
  • High CPU usage across all CPUs: Identify whether SQL Server or another process is consuming CPU. If another process is the cause, address or move it.
  • Low physical or virtual memory:
    • Check the Application event log for “Your system is low on virtual memory.”
    • In Task Manager → Performance → Memory, verify that memory isn’t fully consumed.
    • In Perfmon, monitor:
      • Process\Working Set (per-process memory usage)
      • Memory\Available MBytes (overall free memory)
  • Slow I/O at OS level:
    • In Task Manager → Performance → Disk, check if disks are at or near 100% active time.
    • In Perfmon, monitor:
      • LogicalDisk\Disk Bytes/sec
      • LogicalDisk\Avg. Disk sec/Transfer
  • Power plan: Ensure the server is not using a power plan that throttles CPU (see the guidance on slow performance when using the Balanced power plan).

4. Check for SQL Server I/O bottlenecks

If the OS shows disk pressure or the workload is I/O heavy, investigate I/O from SQL Server’s perspective:

1. Check for hardware/storage issues:
   • SAN misconfiguration (switches, HBAs, cables, storage layout).
   • Exceeded I/O capacity on shared storage (other servers saturating the same SAN).
   • Outdated or problematic storage drivers/firmware.
2. Identify and tune high-I/O queries:
   • Find queries with very high logical reads/writes and tune them (indexes, query rewrites) to reduce I/O.
   • Ensure statistics are up to date so the optimizer can choose efficient plans.
   • Consider schema or query redesign if certain patterns are inherently I/O-heavy.
3. Check for filter drivers on data volumes:
   • Exclude SQL Server data/log/backup folders from antivirus or other file-system filter scanning.
   • Work with vendors to fix any filter driver that heavily processes I/O.
4. Check for other applications saturating I/O:
   • On the same machine: identify non-SQL processes issuing heavy I/O and tune or relocate them.
   • On shared SAN: coordinate with the SAN administrator to balance I/O across servers.
5. Check for memory pressure inside SQL Server

Low memory or memory pressure in SQL Server can slow queries (for example, waits on RESOURCE_SEMAPHORE or RESOURCE_SEMAPHORE_QUERY_COMPILE).

1. At the OS level, again check:
   • Memory\Available MBytes
   • Process(*)\Working Set
   • Process(*)\Private Bytes
2. Inside SQL Server:
   • Query sys.dm_os_memory_clerks or run DBCC MEMORYSTATUS to see which components are consuming memory.
   • Review the SQL Server error log for error 701 (out-of-memory conditions).
3. If memory pressure is confirmed, adjust max server memory, reduce competing workloads, or tune queries that require large memory grants.
4. Check for blocking and concurrency issues

Prolonged blocking can make the entire application appear slow or unresponsive.

1. Identify blocking chains:
   • Query sys.dm_exec_requests and inspect blocking_session_id.
   • Or use sp_who2 and check the BlkBy column.
2. Identify the head blocker session and the query it is running.
   • If the head blocker is idle but still holding locks, there may be an orphaned transaction from the application.
3. Tune or redesign the blocking query:
   • Make it run faster (indexes, query rewrite).
   • Reduce the number of statements inside a transaction.
   • Review and adjust transaction isolation levels if appropriate.
4. Application connectivity and driver considerations

If the application uses ODBC/OLE DB or other drivers to connect to SQL Server 2025, slowdowns can also be caused by connection-level issues (DNS, authentication, encryption):

• Ensure connections use the appropriate server name (often FQDN plus port) and that DNS resolution is fast.
• Confirm that authentication is using Kerberos rather than falling back to NTLM where possible; missing SPNs can cause NTLM fallback and latency.
• If login latency is specifically noticeable after the upgrade, correlate with the PBKDF2 login hashing known issue and apply any recommended mitigations from the SQL Server 2025 known issues article.

8. Next steps

After these checks:

• If the slowdown is tied to login/authentication or many databases, prioritize the SQL Server 2025 known issues and their workarounds (PBKDF2 login hashing and trace flag 15608 for many databases).
• If the slowdown is general, follow the end-to-end path: application vs SSMS comparison → OS health → I/O → memory → blocking.
• Use the detailed articles referenced below for deeper investigation of I/O and memory issues.

References:

• SQL Server 2025 known issues
• Troubleshoot entire SQL Server or database application that appears to be slow
• Queries have been running really slowly since upgrading the database to SQL Server 2025. - Microsoft Q&A
• Microsoft Access Linked Table To Sql Server Express via ODBC 17 or ODBC 18 Driver - Microsoft Q&A
• How to fix SQL Server installation error and run successfully - Microsoft Q&A
• Act! V22: Windows 11 preventing installation of ACT! V22because of SQL and Shell issues. Help? - Microsoft Q&A
• Error While Installing SQL Server 2022 / 2025 - Microsoft Q&A