Here is a roundup of recent security updates for SQL Server from the SQL Server Blog announcements.

Security Updates: August 2025

• Security Update for SQL Server 2022 RTM CU20
• Security Update for SQL Server 2022 RTM GDR
• Security Update for SQL Server 2019 RTM CU32
• Security Update for SQL Server 2019 RTM GDR
• Security Update for SQL Server 2017 RTM CU31
• Security Update for SQL Server 2017 RTM GDR
• Security Update for SQL Server 2016 SP3 Azure Connect Feature Pack
• Security Update for SQL Server 2016 SP3 GDR

SQL Server Delivery Model:

The SQL Server team uses a scheduled delivery model for releasing fixes and product updates. These security updates are part of Microsoft’s Servicing models for SQL Server that started with the release of SQL Server 2017. In the scheduled delivery model, a customer can receive a fix to address their most critical situations in a reasonable time. Therefore, the SQL Server team has created the following delivery mechanisms.

• A General Distribution Release (GDR) update is a patch that Microsoft releases for critical issues. They often address security problems, but not exclusively. They may be available through Windows Update and sometimes are for versions no longer supported.
• A Cumulative Update (CU) release includes all the security fixes, improvements, and occasionally new features for a major version of SQL Server since its Release to Manufacture (RTM). These are available every month for the first year of a version, and then approximately every two months until the version stops receiving mainstream support (typically 4-5 years). As of January 2024, SQL Server 2022 is on a bi-monthly servicing release schedule. SQL Server 2019 has been transitioned to extended support as of Feb 28, 2025.

Choosing Between GDR and CU updates

You can choose either GDR or CU updates depending on your corporate policy or patching plan, but you cannot easily switch from CU to GDR. It is recommended to stay up to date on the CU path and test the updates in a development or staging environment before deploying to production.

So why choose the GDR path? One main reason is that testing non-critical fixes can be costly and time-consuming. An organization may lack the resources to verify all the possible changes, so only critical GDR updates are implemented in those environments.