SQL Server 2017 Cumulative Update 14: What You Need to Know

SQL Server 2017 Cumulative Update 14 (CU14) delivers over 30 bug fixes addressing query execution, backup and restore operations, and security vulnerabilities. It also introduces CLR assembly support in read-only memory-optimised tables, expanding what database developers can do with In-Memory OLTP. If you're running SQL Server 2017 in production, this update is worth your attention.

Keeping SQL Server patched isn't just good hygiene. Unpatched instances are a genuine operational risk, and cumulative updates like CU14 often contain fixes for issues that only surface under specific workload conditions. You might not have hit them yet, but that doesn't mean you won't.

What Is a SQL Server Cumulative Update?

Microsoft releases cumulative updates (CUs) for SQL Server on a regular cadence, typically every 8 weeks for actively supported versions. Each CU is cumulative, meaning it contains all the fixes from every previous CU for that version. You don't need to install CU1 through CU13 before applying CU14. You apply the latest CU and you're current.

This is different from Service Packs (which Microsoft no longer releases for SQL Server 2017 and later) and General Distribution Releases (GDRs), which are reserved for critical security patches only. Cumulative updates cover the broader range of bug fixes, performance improvements, and feature enhancements.

SQL Server 2017 CU14 corresponds to build number 14.0.3076.1 and was released in March 2021. It's available through the Microsoft Download Center and can also be applied via Windows Server Update Services (WSUS) if your environment is configured for that.

What Does SQL Server 2017 CU14 Fix?

The full fix list runs to over 30 items. The areas covered include:

  • Query execution and query processor correctness issues
  • Backup and restore reliability improvements
  • High availability and Always On Availability Groups behaviour
  • In-Memory OLTP (Hekaton) stability
  • Replication components
  • Security updates addressing known vulnerabilities

A few of these fixes address issues that could cause query plans to regress or produce incorrect results under specific conditions. That's not theoretical. Query correctness bugs are among the most operationally dangerous issues a SQL Server instance can have, because incorrect results don't always generate errors. They just silently return wrong data.

If you're running workloads that involve complex query plans, partitioned tables, or parallel query execution, reviewing the full KB article is worthwhile. Microsoft's support article for CU14 is KB5005622, available at the Microsoft support site.

What's the Notable Enhancement in CU14?

The headline feature in SQL Server 2017 CU14 is support for CLR assemblies in read-only memory-optimised tables.

To understand why this matters, some context helps. Memory-optimised tables (introduced in SQL Server 2014 as part of the In-Memory OLTP engine) store data in memory rather than on disk, using a lock-free, latch-free architecture to deliver significantly higher transaction throughput for the right workloads. Organisations running high-frequency transaction processing, session state management, or caching layers inside SQL Server often use memory-optimised tables to reduce contention and latency.

Prior to CU14, CLR (Common Language Runtime) functions and stored procedures couldn't be used directly with read-only memory-optimised tables. CLR integration allows developers to write database objects in .NET languages like C# or VB.NET, which is useful for complex business logic, string manipulation, or custom aggregations that are awkward to express in T-SQL.

CU14 removes that restriction. You can now use CLR functions and stored procedures against read-only memory-optimised tables, which gives developers more flexibility when building solutions on top of In-Memory OLTP without having to work around the limitation by copying data to disk-based tables first.

For most production environments, this won't be a day-one change you implement. But if your development team has been working around this limitation, it's worth knowing the restriction is lifted.

How Should You Apply SQL Server 2017 CU14?

Applying a cumulative update to a production SQL Server instance requires a structured approach. Rushing a patch deployment without testing is how you turn a maintenance window into an incident.

Follow these steps:

  1. Review the KB article. Read KB5005622 in full. Understand which fixes apply to your environment and whether any known issues are documented for the update itself. Microsoft sometimes notes caveats for specific configurations.

  2. Test in a non-production environment first. Deploy CU14 to a dev or staging instance that mirrors your production workload as closely as possible. Run your application test suite. Check for query plan regressions using Query Store if it's enabled.

  3. Back up everything before patching production. Take a full backup of all databases, including system databases (master, msdb, model). Verify the backups are readable before you proceed.

  4. Plan a maintenance window. SQL Server cumulative updates require a service restart. Schedule this during low-traffic periods and communicate the downtime to stakeholders.

  5. Apply the update. Run the CU installer on the SQL Server host. The installer will detect the existing SQL Server instance and apply the update. For clustered instances, follow Microsoft's documented rolling upgrade procedure to minimise downtime.

  6. Verify the build number post-installation. After the update, confirm the build is correct by running:

SELECT @@VERSION;

You should see build 14.0.3076.1 or higher in the output. If you're managing multiple instances, you can query the build number across linked servers or use a centralised monitoring tool to confirm patch compliance.

  1. Monitor after patching. Watch for any unusual query behaviour, wait statistics changes, or error log entries in the 24-48 hours following the update. Use Query Store to compare plan performance before and after if you have historical baselines.

Why Staying Current on SQL Server 2017 Matters

SQL Server 2017 entered Extended Support in October 2022, which means it no longer receives new features or cumulative updates from Microsoft. Security patches (GDRs) are still released under Extended Support, but you're no longer getting the bug fixes that come with cumulative updates.

That context matters for organisations still running SQL Server 2017. If you're on an older CU, you're carrying known bugs that Microsoft has already fixed. Applying the latest cumulative update before the Extended Support window closed was the last opportunity to get those fixes baked in. If you're on CU14 or later, you're in a better position than instances still sitting on the RTM build or early CUs.

For organisations still running SQL Server 2017, the longer-term question is migration planning. SQL Server 2017 reaches end of Extended Support in October 2027. That's not far away in infrastructure planning terms, particularly if you're looking at SQL Server 2022 or Azure SQL as the target platform.

Key Takeaways

  • SQL Server 2017 CU14 (build 14.0.3076.1) includes over 30 bug fixes covering query execution, backup and restore, Always On, and security vulnerabilities.
  • The notable enhancement is CLR assembly support in read-only memory-optimised tables, giving developers more flexibility with In-Memory OLTP workloads.
  • Always test cumulative updates in a non-production environment before deploying to production, and take verified backups before patching.
  • SQL Server 2017 is now in Extended Support and no longer receives cumulative updates. Applying the latest CU before that window closed ensures you have all available bug fixes.
  • Organisations still on SQL Server 2017 should be actively planning migration to a supported version ahead of the October 2027 end-of-support date.

If you're unsure which cumulative update level your SQL Server instances are running, or you need help building a structured patching process across your environment, DBA Services can help. Our SQL Server health checks include a full audit of patch levels, configuration settings, and known vulnerability exposure across your entire SQL Server estate. Contact us to find out more.