What’s Changing and Why

The change Microsoft is making is related to an information disclosure security vulnerability found in CVE‑2026‑20833. To fix this vulnerability Microsoft is stopping the default use of the RC4 encryption algorithm in Kerberos authentication. RC4 encryption has been around since the 80s, has several known vulnerabilities associated with it, and is no longer recommended for use in production environments. The specific risk is “Kerberoasting” an attacker requesting service tickets and cracking the weaker RC4 encryption offline to recover service account passwords.

How Microsoft Has Rolled This Out

Microsoft has been preparing for these changes in phases since January 2026. The first step was an Audit phase, which started recording messages in domain controller event logs. In the System event log, watch for the new events created specifically for this change:

• Event ID 201, 202, 206, 207 – RC4 default disablement / at-risk interactions and service accounts
• Event ID 205 – logged when an explicit configuration still allows RC4

In the Security event log, you can also review:

• Event ID 4768 – Kerberos Authentication Service (AS request / Ticket Granting Ticket)
• Event ID 4769 – Kerberos Service Ticket Operations (Ticket Granting Service – TGS)

Inside these events, an encryption type of 0x17 indicates RC4 is being used.

The next change came with the Windows update in April 2026, which moved domain controllers into enforcement mode by default . This blocked RC4 connections from non-compliant devices for accounts using the default encryption configuration. If you started encountering issues after the April update, you could modify the Active Directory account and set the attribute msDS-SupportedEncryptionTypes to include RC4 (0x24). This was meant to be a workaround, not a permanent fix.

The final phase arrives in July 2026, when the temporary registry escape hatch goes away… Microsoft removes support for the RC4DefaultDisablementPhase registry key that some organizations used to postpone the change. After July, that delay option is gone, and you’ll no longer have the choice of putting off tomorrow what you now get to fix today. (Note: explicitly configured per-account overrides are still honored even after July but relying on them keeps you exposed to the very vulnerability this change exists to close, so they should be a controlled last resort, and a plan to open up vulnerabilities, not succeed…)

What to Review in Your Environment

The key parts of your environment that should be reviewed are service accounts, applications using Kerberos or Windows Authentication, older systems, and with SQL Servers: linked servers and the accounts being used. Have a sysadmin review your domain controller event logs for the event IDs above and check whether RC4 (0x17) is in use. A bigger lift will be verifying your application libraries and drivers are up to date and checking whether older software in your environment supports AES encryption.

“We Deployed April and Had No Problems… Do I Still Need to Check?”

You may be asking yourself, “We’ve deployed the April update and haven’t had any problems, do I really need to check all these things?” The impact of not checking means that in July you may start to experience one, or all, of the following:

• Failed database connections (Windows-authenticated SQL Server)
• Linked server authentication failures
• Application login issues
• Service startup failures
• Kerberos delegation failures

If your environment is up to date on Windows updates and your system administrators have kept up with this change, your chances of experiencing any of these issues are much lower. As we all know, that chance is almost never zero, and taking one last look isn’t going to hurt. If anything, you may find the one thing that was overlooked which could save the company from coming to a grinding halt when RC4’s default support ends for good.

Where to Learn More

If you would like to read more about the change, you can look up CVE‑2026‑20833 or review Microsoft’s official guidance. Reviewing your environment now can help ensure a smooth transition and avoid unexpected disruptions.

• How to manage Kerberos KDC usage of RC4 (CVE-2026-20833) — Microsoft Support (KB5073381)
• Detect and Remediate RC4 Usage in Kerberos — Microsoft Learn
• Kerberos and the End of RC4: Protocol Hardening and Preparing for CVE‑2026‑20833 — Microsoft Community Hub

Check Your SQL Server Security and Upgrade!

While you are at it – don’t forget to check your own SQL Server security. We can definitely help with our health checks, but you can also just download our free SP_CheckSecurity proc and check your own security. And if you are on an unsupported SQL Server (which will include SQL Server 2016 soon) Check out some of our posts on SQL Server 2016’s final countdown and upgrade best practices.

The post RC4 Is Going Away in July 2026: What CVE-2026-20833 Means for Your SQL Server and Windows Environment appeared first on SQL Server Consulting - Straight Path Solutions.

SQL Server 2016 was the version where Microsoft really started giving us the good stuff for free. Query Store, Columnstore for everyone, Always Encrypted, Availability Groups that worked, and more. Plus, the Service Pack 1 feature additions made Standard Edition folks feel like they weren’t second-class citizens anymore.

But that was a decade ago, and as of July 14^th, 2026, SQL Server 2016 is out of support. No more updates or hotfixes, so it’s well past the time to upgrade to a newer version. I know upgrades can seem painful, and we can help with that, but on the other side of that upgrade are many features added since SQL Server 2016 that could make your life easier.

Let’s walk through some of my favorite new features from each version, in the style of an executive summary in case you want to copy/paste to your supervisors to convince them to upgrade. I’ll keep the descriptions short, tell you why you should care, and link to pages with more info should you want to learn more.

SQL Server 2017

SQL Server 2017 shipped only 16 months after 2016, which by Microsoft’s historical standards is practically a patch. Still, they managed to slip in some real gems.

SQL Server on Linux

We were all assured for decades would be an icy day in a place hotter than the desert here in Arizona before Microsoft ever supported Linux, but starting with 2017 you can run the database engine on Red Hat, Ubuntu, SUSE, or in a Docker container. If you work somewhere that has a Linux-first policy, SQL Server is no longer a non-starter, and if you’re a DBA, containerized SQL Server means you can spin up a test instance in roughly the time it takes to refill your coffee. Read more from Microsoft.

New String Functions

Developers, rejoice! STRING_AGG, TRIM, TRANSLATE, and CONCAT_WS may seem like cute new functions, but STRING_AGG alone eliminates the XML PATH abomination we’ve been using since SQL Server 2005. If you’ve never written FOR XML PATH(”) followed by STUFF to concatenate rows, count yourself lucky because now you’ll never have to. Read more from Aaron Bertrand.

SQL Server 2019

This version has been very stable for years, and I would guess as of this writing it is the most popular version with our clients. And it had a few neat feature additions too (and no, I’m not talking about the troublesome scalar UDF inlining and all its requirements.)

Accelerated Database Recovery (ADR)

Before ADR, if a long-running transaction got killed or the server crashed mid-flight, SQL Server had to chew through every log record from the oldest active transaction before the database came back online. For a well-behaved OLTP system that’s fine, but for a system where somebody just ran a three-hour ‘UPDATE’ with no ‘WHERE’ clause, recovery could take hours. That’s real pain.

ADR uses a persisted version store (similar to RCSI) so rollbacks and recovery are nearly instantaneous regardless of transaction size. Crash recovery can go from minutes to seconds. Read more from Microsoft.

Memory-Optimized Tempdb Metadata

If you’ve ever worked on a busy OLTP system where everybody and their uncle is creating and dropping #temp tables, you’ve seen the PAGELATCH_* waits on the tempdb system tables. It’s a classic contention point that no amount of “add more tempdb files” will ever fully solve.

SQL Server 2019 lets you shove the tempdb system metadata tables into memory-optimized (Hekaton) tables, eliminating that latch contention entirely. Doing this requires a server-level setting and a restart, but for the right workload it’s night and day. Note, this feature seemed to have gotten some big improvements in SQL Server 2022. (Watch Haripriya Naidu’s video with more)

SQL Server 2022

The marketing pitch for 2022 was “the most Azure-connected SQL Server ever!” which is great if you’re in Azure and slightly less exciting if you’re not. But even setting aside the cloud stuff, there are some cool features here.

Query Store Is On By Default (Finally)

New databases created in 2022 have Query Store turned on out of the box. It took them six years since the 2016 release, but hey, these things take time. Query Store is also now supported on readable secondary replicas in Availability Groups, which means your read-only reporting workload is finally observable. Read more from Microsoft.

Query Store Hints

You can now apply query hints *without changing application code*. Specifically, you use sys.sp_query_store_set_hints to attach hints like RECOMPILE to a specific query_id in the Query Store. For anyone who’s ever had to performance tune a vendor-supplied application where you can’t change the SQL, this is a gift. Read more from Microsoft.

S3-Compatible Object Storage for Backup/Restore

You can now BACKUP TO URL and RESTORE FROM URL against S3-compatible object storage, and not just Amazon S3 but also Dell, HPE, Pure Storage, NetApp, MinIO, and others. For anyone running SQL Server in a hybrid shop, this is a much simpler backup target than wrestling with file shares or Azure-only URLs. Read more from Microsoft.

Contained Availability Groups

In every pre-2022 Availability Group (AG), you had to manually keep logins, SQL Agent jobs, permissions, and linked servers in sync across replicas. (Did you ever forget to add logins on the secondary, fail over, and hear the lamentations of the users?) With contained AGs, users/logins/permissions/jobs live inside the AG itself using contained master and msdb databases so across replicas these consistencies are handled for you. Read more from Microsoft.

SQL Server 2025

SQL Server 2025 went General Availability (GA) on November 18, 2025. This is the first release in a long time where there are several situations to push clients to upgrade faster rather than slower.

Standard Edition Finally Gets Some Love

For the first time since 2016 SP1, Standard Edition got a real upgrade, including:

• 32 cores (up from 24)
• 256 GB RAM (up from 128 GB)
• Resource Governor is now included in Standard (it was Enterprise-only forever)
• There’s a new Standard Developer Edition so you can build dev/test environments that actually match your Standard production limits

If you’re a shop that has been running Standard Edition for years and feeling the squeeze, this alone is a reason to skip 2022 and jump straight to 2025. More from Microsoft.

(Related: Express Edition gets some more love too, which now supports 50 GB databases, up from 10 GB.)

Native Vector Type and Vector Search

Yes, this is the “AI” feature, and yes, it’s real. SQL Server 2025 has a native VECTOR data type, a vector index powered by DiskANN, and functions like VECTOR_DISTANCE, VECTOR_SEARCH, and AI_GENERATE_EMBEDDINGS that let you call out to an embedding model from T-SQL. Whether or not you personally need to build a RAG chatbot, the broader implication is big: your database can now do semantic (meaning-based) searches, not just keyword matching. Read more from Andy Yun.

Optimized Locking

Optimized Locking uses Transaction ID (TID) locking and Lock After Qualification (LAQ) to dramatically reduce lock memory use and lock escalation. For high-concurrency OLTP workloads, Microsoft has published telemetry showing 80% of locks being skipped in some cases. It requires ADR to be enabled, but no application changes. Read more from Microsoft.

Native JSON Type + JSON Indexes

Since 2016 we’ve stored JSON as NVARCHAR(MAX) and lived with it. 2025 introduces a real native JSON data type (binary-stored, up to 2 GB per document) and lets you create JSON indexes on specific path expressions. There are still some quirks with JSON_VALUE not always using the index, so test carefully. Read more from Microsoft.  

But wait, there’s more

Just so you know, that was not a comprehensive list. There have been many new features added since SQL Server 2016 that, depending on your situation, could benefit your organization. These other features are all included in SQL Server 2025:

• Fabric Mirroring if you have Microsoft Fabric reasons.
• Graph Database Support for those modeling hierarchies or social networks.
• Ledger to give you a tamper-evident (cryptographically verifiable) record of every change made to specific tables.
• Optional Parameter Plan Optimization (OPPO) can now generate different execution plans adapted to the runtime parameter values for “kitchen sink” queries.
• Regex Support with a bunch of new T-SQL commands.
• TDS 8.0 / TLS 1.3 support for the security-minded folks.
• ZSTD Compression allows for faster, small backups than the default compression.

Thanks for reading. Now go forth and plan to upgrade your SQL Server 2016 instances.

The post SQL Server 2016 – the Final Countdown: Key Features from SQL Server versions 2017–2025 appeared first on SQL Server Consulting - Straight Path Solutions.

But the code a Codex creates meets a single need: to ship. It works through the process line by line, having learned from decades of training corpus material on the most popular languages, libraries and frameworks, and does its best to cobble together that vast background of knowledge into a product. However, when you take a look at what it creates, in some cases it’s almost incomprehensible. You can try this yourself: Open your favorite AI Codex tool and ask it to build a Single Web Page App (SWA) that does something non-trivial, like reading and writing data to a database like SQLite. Ensure you have various buttons and menus to do that work. Vibe code that until it works.

Now open the assets it created. First, you’ll notice how massive the page is. Now change two of the more non-trivial menu items or button actions that the Codex created to do something else. Don’t just rename the button or add a color, have it do some work. My observation is that if you are not an experienced developer in the framework and code the Codex picked, you won’t be able to do that, or at best you’ll break it and need the Codex’s help again. And when it does, the codebase will become even more massive.

If you are an experienced developer, you can probably suss out what the Codex did and make the change. But after the initial amazement that it coded the brief, you will begin to see things that you would have done very differently. I’ve opened some of the Codex results, and I am actually pretty shocked that it wrote what it did. I find myself saying “why not just do a single line of a lambda function rather than these 58 lines it wrote?”

It’s not hard to write software that you can deploy. It’s really hard to check that software for edge case bugs, security violations, optimizations, and package it for deployment into an enterprise. Depending on how large the deployment becomes, most Codex’s start to choke, lose context and memory and start to hallucinate when you pass the entire solution back in and say “Revise this to include a custom sort the customer wants.” Try that now with your single page. Add a new, non-trivial function to the base. Then run a code optimization on it. Then pass it through a security check.

This is why you haven’t seen Codex developed software replace an SAP or some large enterprise software package. You need an extremely high level of software development process and procedure over decades and decades to release something like that.

To be clear, I am not saying “don’t vibe code things”. You should use this amazing new tool for things you need to create. The advice I give my clients is to develop in a modular way, as atomically as possible. Micro-services, Service Oriented Architectures, or just making sure each module is small and encapsulated and talks to other modules via an endpoint will serve you well. Then you can swap out, optimize, check and maintain small chunks of code.

This is today. Tomorrow AI will start eating away at these problems, and this post won’t be as accurate. But it illustrates an important point: You need to be smarter than what you are using as the tool. You need to know what it should do, and why it might make the choices it does. It will help in your prompting, architecting, “Brain” files and so on to get the best results.

Remember: It’s a tool, not a replacement for your professionalism.

The post AI Builds to Ship (But not to Maintain) appeared first on SQL Server Consulting - Straight Path Solutions.

If you’re planning on upgrading from SQL Server 2016 to the current version of SQL Server 2025, it would be helpful to note some of the features from versions since 2016 that are no longer supported. By that I’m talking about those things classified as “deprecated” (no longer supported) or “discontinued” (removed from the product). Let’s take a look at these features and say our goodbyes, organized by versions.

SQL Server 2017

So here’s a fun fact I found while researching deprecated features for a SQL Server 2016 migration. When you pull up the Deprecated Database Engine features in SQL Server 2017 page on Microsoft Learn and scroll down a bit, Microsoft comes right out and tells you:

“This list is identical to the SQL Server 2016 (13.x) list. There are no new deprecated or discontinued Database Engine features announced for SQL Server 2017 (14.x).”

In other words, SQL Server 2017 was a freebie on the deprecation front. Nothing new got flagged for removal. Which was great for us, but it also means if you’re migrating from SQL Server 2016 or 2017 to something newer, the same missing features could bite you when you upgrade to a higher version.

SQL Server 2019

SQL Server 2019 was fairly quiet in the deprecation department. According to the Deprecated Database Engine features in SQL Server 2019 page, only two items got newly flagged, but unfortunately they’re both big ones for folks with BI and data governance workloads.

Data Quality Services (DQS)

DQS is the knowledge-base-driven data cleansing feature from the Microsoft BI era. It lets you build domains of valid values and then match/cleanse data against them. If you’re not using it, great – skip ahead. If you are, well, consider this your heads up: it still works in SQL Server 2019 and 2022, but Microsoft removed it entirely in SQL Server 2025.

Why it matters: Any ETL workflow, SSIS package, or MDM process that leans on DQS won’t just be deprecated on SQL Server 2025 – it simply won’t be there at all. Start evaluating alternatives now (Azure-based cleansing services, third-party tools, or custom solutions) before somebody tells you the SQL 2025 upgrade is happening next week.

Master Data Services (MDS)

Same story as DQS. MDS is Microsoft’s master data management platform, used for building golden records of customers, products, accounts, whatever. Deprecated in 2019, it still works in 2022, but it also was removed in SQL Server 2025.

Why it matters: If you’ve built hierarchies, business rules, and workflows in MDS, that’s a significant migration project waiting for you. Don’t let it surprise you during the upgrade meeting.

Also, some database scoped configuration options were quietly retired in SQL Server 2019. None of these will probably wake you up at 2am, but they’re worth knowing about if you inherited scripts from an earlier era. Here are some examples.

DISABLE_BATCH_MODE_ADAPTIVE_JOIN

This was the off switch for the adaptive joins feature (introduced in SQL Server 2017). In 2019, Microsoft decided you shouldn’t need a knob for that anymore, so they removed it.

DISABLE_BATCH_MODE_MEMORY_GRANT_FEEDBACK

Same idea, different feature. Memory grant feedback no longer has a dedicated disable switch at the database scoped configuration level.

DISABLE_INTERLEAVED_EXECUTION_TVF

The disable switch for interleaved execution of multi-statement table-valued functions is gone too.

Why any of these matter: If you ran across any older “performance tuning” scripts from around 2017-2018 that attempted to flip these switches, they’ll now throw errors on SQL 2019+. Clean those up before running them post-upgrade.

SQL Server 2022

This is where things get interesting. SQL Server 2022 flagged several notable features for deprecation, per the Deprecated Database Engine features in SQL Server 2022 page.

Distributed Replay

Remember Distributed Replay? It was (is?) the multi-machine workload replay tool. Think of it as SQL Server Profiler’s cousin that could replay a trace from several client machines at once to simulate a real production load. This has been very handy for pre-upgrade testing for manyof us.

Except now it’s deprecated. Even worse: it’s not even shipped with SQL Server 2022 anymore. The Distributed Replay overview page bluntly says:

“Distributed Replay is deprecated as of SQL Server 2022 (16.x)… The Distributed Replay Controller has been removed from SQL Server 2022 Setup.”

Why it matters: If your team uses Distributed Replay as part of your pre-upgrade testing workflow (and if you’re running production workloads in the hundreds of batches per second, you might be), you’ll need to stop, because it’s removed from setup in 2022. Microsoft suggests RML Utilities which includes ostress as an alternative. It’s not a perfect replacement, but it’s what we’ve got.

Machine Learning Server (Standalone)

Not to be confused with SQL Server Machine Learning Services (in-database R/Python), Machine Learning Server was the standalone product for running R and Python workloads outside SQL Server. Extended support for the standalone product ended on July 1, 2022, so this one was already essentially dead before 2022 even shipped.

Why it matters: If you were running a standalone ML Server as part of your data science stack, you need to migrate to Azure Machine Learning or some other platform. The in-database Machine Learning Services feature inside SQL Server is still supported, so don’t confuse the two.

Stretch Database

Stretch Database was the feature that let you transparently migrate cold rows from an on-premises table to Azure SQL Database while making them still queryable. The actual performance may not have been the best, which might be why it never really caught on. Anyhow, now Stretch Database is deprecated.

Here’s the best part: even if you ignored the deprecation, Microsoft discontinued Stretch Database in all supported versions of SQL Server as of July 2024. So it’s gone. If you had it enabled, you had to migrate your data back on-prem before July 2024 or it became inaccessible.

Why it matters: Hopefully you already handled this, because July 2024 is way far in the rearview mirror. But if by some chance you have a dusty old instance still running Stretch Database, you’ve got a data retrieval problem you need to deal with several yesterdays ago.

SQL Server 2022 really went big with the discontinuation list, cleaning house on a lot of “big data” tech that never really delivered on its promise. Here are some more features in the graveyard.

PolyBase Scale-Out Groups

PolyBase is still around as a data virtualization feature, but the scale-out group functionality (where you could cluster multiple SQL Server instances to parallelize external queries) has been removed entirely from SQL Server 2022.

Why it matters: If you built any kind of PolyBase cluster for querying Hadoop or external data at scale, that architecture needs to be rethought. PolyBase as a scale-up feature on a single SQL Server instance still works though.

Hadoop (HDFS) External Data Sources for PolyBase

If you had PolyBase external data sources configured with TYPE = HADOOP, those are no longer supported in SQL Server 2022. You have to manually recreate them using the new connectors. Similarly, if you were connecting to Azure Storage with the old wasb[s] or abfs[s] syntax, you need the new abs and adls connectors respectively.

Why it matters: This is not a “just upgrade and it works” situation. If your shop was using PolyBase to federate queries against Hadoop or Azure Storage, you have actual T-SQL to rewrite.

Machine Learning Services Packages Removed from Setup

Starting with SQL Server 2022, Microsoft stopped bundling certain R and Python packages with the install. Specifically: microsoftml (Python), olapR (R), sqlrutils (R), and MicrosoftML (R). You can still install them as custom packages, they’re just no longer out-of-the-box.

Why it matters: If you upgrade a SQL Server with in-database R/Python scripts that import these packages, you’ll get runtime errors unless somebody installs them manually on the new instance. Check your sp_execute_external_script calls.

SQL Server Big Data Clusters

SQL Server Big Data Clusters – the 2019-era Kubernetes-based SQL + Spark + HDFS platform – was officially retired as of February 28, 2025. It’s no longer a thing in SQL Server 2022 either.

Why it matters: If you deployed BDC, you have a whole architecture to replace. From what I can tell, Microsoft now recommends a mix of SQL Server 2022 with object storage, Azure Synapse (now largely replaced by Microsoft Fabric, but I’ll get to that), or Azure Machine Learning for the predictive workloads.

SQL Server 2025

SQL Server 2025 is still fairly new (at least it was at the time I’m writng this), but it’s already flagged two configuration-type features. Per the Deprecated Database Engine features in SQL Server 2025 page:

Hot Add CPU

This was the feature that let you add CPUs to a SQL Server without restarting the service. It might have been useful back in the day when VMs couldn’t really be hot-scaled, but it’s now deprecated.

Why it matters: Honestly, if you’re running in modern VM environments, you probably didn’t use this. But if you had any automation that relied on runtime CPU scaling, check it.

Lightweight Pooling (Fiber Mode)

The lightweight pooling sp_configure option – and its corresponding fiber mode – is now officially deprecated. This was an old-school option that switched SQL Server from using threads to using fibers for scheduling, with the supposed benefit of reduced context-switch overhead. In practice, it may have caused way more problems than it solved, and truthfully, I don’t know anyone who actually turned it on.

Why it matters: Just make sure lightweight pooling is set to 0 on your instances (which it should be anyway), and you’re good. If you had it enabled, well, now’s the time to turn it off.

SQL Server 2025 also discontinued some of the deprecated features from the previous version. So they’re gone forevermore.

Data Quality Services (DQS)

Deprecated in SQL Server 2019, as mentioned a few paragraphs ago it is now gone. If you’ve got DQS workloads running, you cannot upgrade to SQL Server 2025 without migrating them first.

Master Data Services (MDS)

Also gone. Same deal as DQS.

Synapse Link for SQL

Azure Synapse Link for SQL was the near-real-time analytics replication feature introduced with SQL Server 2022. It created a change feed from your operational database into a Synapse dedicated SQL pool. Well, it’s discontinued in SQL Server 2025, as in “not supported.” This is presumably because Microsoft is steering everyone toward Mirroring in Microsoft Fabric instead.

Why it matters: If you’re on SQL Server 2022 and using Synapse Link, you’ve got a migration to Fabric Mirroring to plan. The good news is for now Fabric Mirroring supports SQL Server 2016+, so you have options even on older versions.

Purview Access Policies (DevOps and Data Owner Policies)

Purview access policies are discontinued in SQL Server 2025. Microsoft is shifting to the fixed server-level roles model (introduced in SQL Server 2022) for this kind of access management. New roles like ##MS_ServerPerformanceStateReader##, ##MS_PerformanceDefinitionReader##, ##MS_ServerSecurityStateReader##, ##MS_SecurityDefinitionReader##, and ##MS_DatabaseConnector## replace the old Purview policy actions.

Why it matters: If you implemented Purview-based access control on your SQL Servers, you need to rework it using the new server roles. That’s probably not a casual afternoon project.

Now what?

That’s a lot of features. Some are rather obscure, so I’m sure you’re wondering whether or not you are using them. I have good news for you! If you want to find out what deprecated features are being used on your SQL Server instances, you have several tools available to help you.

I was going to finish this post by showing you how you could use instance level counters, extended events, and more to identify deprecated features in your SQL Server instance…but Stephen Planck has already written a post that shows you how to do those things to find deprecated features in SQL Server. Do check it out, and take notes.

The post SQL Server 2016 – the Final Countdown: Features Deprecated and Discontinued Since SQL Server 2016 appeared first on SQL Server Consulting - Straight Path Solutions.

That’s right: it’s time to plan to retire SQL Server 2016 to Del Boca Vista. And soon.

This post is the first in a series we are calling “SQL Server 2016 – The Final Countdown.” (Yes, you may now have that song stuck in your head for the rest of the day, and you are welcome.) Over several posts we are going to walk through what you ought to know before this version rides off into the sunset, but today we start with the big one: the end of support, what it actually means, and why you should care a good deal more than you probably do right now.

And although “End of support” sounds like one of those vague corporate phrases that lives inside an email you never opened, I assure you it is a real concern. It has a date, it has consequences, and if you are running SQL Server 2016 in production, it has your organization’s name on it.

Let’s get to it then.

The Timeline (or How We Got Here)

Every version of SQL Server gets two phases of support from Microsoft.

Mainstream support is the good years. You get security patches, cumulative updates with bug fixes and feature tweaks, and the ability to call Microsoft when something goes sideways at 2:00 AM. For SQL Server 2016, mainstream support ended on July 13, 2021. If you didn’t notice, it’s probably because you don’t regularly apply updates to your instances. The rest of us may be silently judging you.

Extended support is the twilight years. No new features, no non-security bug fixes, just critical security patches and a phone number you hope you never have to call. SQL Server 2016 has been living in this phase for a 5-year period, quietly collecting security updates while many folks have moved on to SQL Server 2022 or 2025.

And this is the main thing: Extended Support for SQL Server 2016 ends on July 14, 2026.

Mark it on the calendar, set a reminder, and/or tattoo it somewhere tasteful, because after that date, SQL Server 2016 is, for all practical purposes, on its own.

What “End of Extended Support” Actually Means

Since we’re friends and I want you to take away more than just an epic 80s song from this series, let’s be clear about this. When extended support ends, here is what stops:

• No more security patches. This is the big one. When a new vulnerability turns up in the SQL Server engine after July 14, 2026, and trust me, they will keep turning up, Microsoft will not be fixing it for 2016. That hole stays open. Forever.
• No more bug fixes. Found a weird bug? Congratulations, that is now a permanent feature.
• No more technical support. You cannot open a support case. There is no one to call. The number has been disconnected, metaphorically speaking.
• No more compatibility updates. As Windows Server, .NET, and your hardware keep marching forward, SQL Server 2016 stays frozen in place, and the gap between them gets a little wider every single year.

Now notice what does NOT happen on July 15, 2026: your instance does not burst into flames. SQL Server 2016 will keep running exactly like it did the day before. And that, my friends, is the trap. Nothing visibly breaks, so it becomes very easy to convince yourself that nothing is wrong.

The Risks of Staying Put

“But it still works, so why bother?” We hear this a lot, usually right before something expensive happens. Here is what you are actually signing up for if you decide to ride SQL Server 2016 past the deadline.

Security risk that only grows. Every month after July 2026, the pile of known, unpatched vulnerabilities gets a little taller. Attackers love unsupported software precisely because those holes never get fixed. You are not standing still; you are slowly falling behind while everyone with bad intentions keeps moving forward.

Compliance and audit headaches. If your organization answers to PCI DSS, HIPAA, SOC 2, ISO 27001, or some other framework of compliance acronyms, then running unsupported software is a “finding” waiting to happen. In our experience, auditors are not impressed by “but it still works.” And they aren’t wrong.

Cyber insurance complications. More and more insurers want to know whether you are running supported software before they pay out a claim, or before they agree to renew you at all. An unsupported database engine is exactly the kind of detail that surfaces in the fine print at the worst possible moment. This could lead to a resume generating event for you and your colleagues.

Vendor abandonment. Software vendors eventually stop certifying their applications against old database engines. At some point your ERP or line-of-business vendor says they no longer support SQL Server 2016, and now you have even more software out of support.

Growing technical debt. Every year you wait, the eventual migration gets bigger, riskier, and more expensive. The version gap widens, the institutional knowledge fades, and the person who set it all up has long since left for greener pastures (probably with supported software). Future You would greatly appreciate if Present You would take care of that migration to a supported version now.

A Quick Word About Extended Security Updates

Now, before someone emails me or adds a sternly worded comment, yes, there is an escape hatch. Microsoft offers Extended Security Updates (ESU) for SQL Server 2016, which buys you up to three more years of critical security patches past July 2026, available either through Azure or your licensing partner. But there are two things about ESU to consider.

• ESU covers critical security patches and nothing else. No bug fixes, no features, no general support.
• The pricing is, how shall I put it, motivational. It climbs every year, starting around 75 percent of your original license cost in year one and escalating sharply from there. By the time you have paid for all three years, you will have spent several times your original license price for the privilege of standing still. Microsoft is not being subtle about wanting you to upgrade, and the invoice makes the argument obvious.

You can use ESU to give yourself breathing room, but it’s best applied for a migration that is already in motion, or at the very least planned. We don’t recommend using it as a clever way to avoid a migration entirely, because that math rarely works out.

Why You Should Care (The Short Version)

Doing nothing is a decision, but ironically it could be the most expensive choice. The deadline is real, the date is fixed, and migrations always take longer than anyone expects. Whether your destination is SQL Server 2022, SQL Server 2025, Azure SQL, or somewhere else entirely, the best time to start planning was last year. The second-best time is today.

In the rest of this series we will dig into the more things you ought to know to further encourage you towards moving to a supported version. For now, go find out where you are running SQL Server 2016 and start planning to migrate if you haven’t already. And if you need some help getting that migration approved, here is something you can copy, paste, and forward to the people who control the budget.

Executive Summary: SQL Server 2016 End of Support

For distribution to leadership and decision makers.

The situation. Microsoft ends extended support for SQL Server 2016 on July 14, 2026. After this date, Microsoft will no longer provide security patches, bug fixes, compatibility updates, or technical support for this version. (Mainstream support already ended on July 13, 2021.)

Why it matters.

• Security: Newly discovered vulnerabilities will never be patched, leaving affected systems permanently exposed.
• Compliance: Running unsupported software can cause failures against PCI DSS, HIPAA, SOC 2, ISO 27001, and similar frameworks, creating audit findings and potential penalties.
• Insurance: Cyber insurance providers increasingly require supported software as a condition of coverage and claims.
• Vendor support: Third-party software vendors will stop certifying their applications against SQL Server 2016.
• Cost: The effort, risk, and expense of migration all increase the longer the upgrade is delayed.

The options.

1. Upgrade to a supported version. SQL Server 2022 or 2025, or migrating to a cloud platform such as Azure SQL. These are the recommendations since SQL Server 2017 or 2019 are already in Extended Support.
2. Purchase Extended Security Updates (ESU) for up to three additional years of critical security patches only. Pricing escalates each year and is intended as a short-term bridge, not a permanent solution.
3. Do nothing and accept the accumulating security, compliance, and operational risk. Not recommended.

Recommended action. Begin planning and budgeting for migration now. Complex environments can take several months to migrate safely, and the deadline is fixed. Starting early reduces risk, cost, and disruption.

Bottom line. SQL Server 2016 will keep running after July 14, 2026, but it will do so without protection, without support, and without a safety net. The deadline is not a suggestion, and waiting only makes the eventual project harder.

The post SQL Server 2016 – the Final Countdown: What End of Support Means and Why You Should Care appeared first on SQL Server Consulting - Straight Path Solutions.

Just Databases

Early on in my mainframe days I worked at the Kenedy Space Center for NASA here in Florida. My first foray into databases on a mainframe was IBM’s Information Management System (IMS). It was a hierarchical database and transaction manager that is still in use, even though it wa developed in the 1960s to track parts for NASA’s Apollo program. Yes, primitive now, but at the time it eventually became a staple for over 95% of the Fortune 1000. It’s still in use, processing billions of transactions every day, even now. 

I also used a data base software application called SQL/DS on the mainframe, which became DB2. I still have a book around my office somewhere with the “System R” logo on it where it was developed at IBM.

In all of those cases, data was just data. We moved from COBOL flat-files to an engine over relational tables, but it was just data. Applications (green-screen terminals, thank you very much) put data in, and took data out. The function of the “database” was to do that as quickly, efficiently, and securly as possible.

Surely You Can do Better than That

And then I disovered and managed and used Oracle. Oracle had *Forms*. It had a reporting system , all built in. And then they added Java! And all kinds of new data types outside text, dates and numbers. 

It was this kind of thing, pioneered by companies like Oracle, that allowed organizations to think about centering their data estate (that became a thing) around a database platform.

SQL Server – the Little Engine That Could

In the late 1980’s, in addition to the mainframes NASA used, we also had IBM’s OS/2. I joined the team that focused on this product, and one of the interesting applications it had was a command-line based database called “Microsoft SQL Server” – version 1.0. It was even client-server, meaning the database engine could run on one computer and another computer (the client) could access it over the (Token Ring) network. I was fascinated with the “Transact-SQL” dialiect of SQL it used. 

IBM and Microsoft broke up over OS/2, and I started my journey with Windows operating sytems, including “Windows NT Advanced Server”. By now I was using SQL Server version 6+. While Microsoft added Stored Procedures and other engine features, they were just that, engine features. For a database engine.

Except one: The opening of the system with the Replication feature. The ability to send some or all of the data in one database to another using a dedicated system. Data could now be used differently by entirely different application needs. And companies started thinking about the database engine a little differently.

SQL Server – Let’s Be a Platform

Then came SQL Server version 7 – a completely rewrite of the platform but with (mostly) backwards compatibility. It included not only a highly capable database engine with a wide suite of programability features, but Microsoft started adding things right in the box that drastically extended the ability of the system to host business-critical data estate functions. One of the most impressive was “OLAP Services”, which as the name suggests, was a full Business Intelligence (then a pretty new term) server. To fill, process and orchestrate that system, they added “Data Transformation Services” or DTS, a feature that was pushed by us administrators far past its intended purpose of Extract, Transform and Load (ETL). 

SQL Server – The Kitchen Sink

Fast forward to SQL Server 2005, and we got all the “S’s”: Analysis Services for BI, Reporting Services for, well, reporting, and Integration Services which is actually hard to pin down. Integration Services does so much that I’ve seen pure Oracle shops buy SQL Server just to use Integration Services for everything from data transforms and movement to a full job system.

Then I Joined Microsoft on the SQL Server team. What an eye-opener for me. This product was massive and had grown FAR beyond a database. You scaled out the data functions to multiple servers, with complicated disk arrangements and multiple network cards.

And from there, more and more features showed up in heavy and rapid fashion. We added every data type you can think of: you could store whole Microsoft Office documents, music, pictures, and search them all. Full text. In-memory.  We added not only geographic datatypes, but geo-spatial datatypes. I had one client using that feature to map out their entire warehouse, down to the shelf dimensions so they could find exactly which boxes would fit where for the most efficient storage.  In a database!

I moved from the SQL Server engineering team to work as a technical pro at Microsoft in the field, I then joined the team that built Azure, and then I joined the team that was implementing Machine Learning at Microsoft. And of course then that went into SQL Server. You could (and still can) run your own self-contained AI constructs and solutions and applications and never leave SQL Server. 

I was also part of the ill-fated “SQL Server Big Data Clusters” – a system ahead of its time that could scale from on-premsises to the cloud, with so many features running in Linux an Kubernetes no less.

Companies large and small, around the world, built their business logic, data processing and analysis, reporting, and now even AI into the SQL Server product.

But it got a bit, well, overwhelming. Having everything, and I mean everything, in the box can make for complex upgrades, complicated troubleshooting, and make it hard to keep up with what the system can really do. 

Adding to this, some of the features are more mature and stable than others. Some very much so. 

SQL Server – Just a Database

Things, as they always do, have changed. Developers are now using scale-out, cloud-first, micro-services, per-server data processing, which feeds much larger more spread-out systems. Data storage is now separated away from (as in my COBOL days of old) from the processing engines that used it. Vendors – even Microsoft – tended to focus on larger distributed sytems.

The expensive licenses of SQL Server doesn’t hold the same value if you’re just using it as a database. Postgres is “free” (not really, but that’s the mindshare) and if your data is small you can use SQLite (love me some SQLite) and the stunningly amazing DuckDB. DuckDB, for me, holds the same excitement level as the SQL Server version 7 days. The little engine that could. 

SQL Server – So Wither Forth?

In some clients I work with, they feel they are being left behind if they don’t move to the newest cloud analytics platforms currently battling for their data budget.

In some cases, after we do a deep audit of their needs, SQL Server still fills the bill quite well. Yes, it needs to be designed and implemented properly, but if you do, there’s a lot going for it. Yes, pricing is pretty high, but compared to cloud costs, it can actually be significantly cheaper.

So – will SQL Server be your “Platform in a Box” or cast aside for cheaper, smaller, faster “Just a Database” products? I’ll fall back here on the most famous saying in the Database Administrator (DBA) world: “It Depends”. Sorry, but there it is. I think for many, many shops, if you take the time to plan, implement and manage it well, SQL Server cannot be beat. It really can’t. 

For some workloads, however, distributed storage and compute is a great idea. If you haven’t investigated  with some of the major systems, I highly recommend you do. Oh, and while you’re at it, play around with DuckDB. It will amaze you with what it can do, directly over storage like Delta/Parquet. And while you’re at it, take a look at some of the newer systems that bypass the “Reporting” layer entirely. I’ve seen some lately that are an absolute sea-change. 

Everything old is new again. 

The post SQL Server: Database or Data Platform? appeared first on SQL Server Consulting - Straight Path Solutions.

For several versions of SQL Server, the maximum log file size was noted at 2 TB. If you ever reach that limit you could find yourself in a Disaster Recovery scenario.

Context

We received an emergency call from a client that noted that their SQL Server instances was unresponsive. (This was an Amazon RDS instance, although that didn’t play much into the ultimate root cause.) The client had some technical staff already looking at the issue, and when we joined the call we were informed that the transaction log for their main production database was completely full, and all transactional activity in the database had stopped.

For many versions, SQL Server has had a default maximum files size of 2 TB on transaction log files. Even though newer versions like SQL Server 2022 and 2025 may say “unlimited”, they aren’t truly unlimited. The current documentation notes that transaction log files still have a 2 TB maximum file size.

Investigation: Why log_reuse_wait_desc Showed REPLICATION

After a quick review, we confirmed that the transaction log for their main production database was completely full, and had reached the maximum size of 2 TB. The log reuse description in sys.databases showed “REPLICATION” as the cause for the log being full.

This instance did not have replication, but the client did have Change Data Capture (CDC) enabled on numerous tables, which also shows up as “REPLICATION” in the lof reuse information. We discovered the CDC capture and cleanup jobs had not been running for weeks, which caused the transaction log to hold transactions and not mark them for reuse.

Unfortunately, before we joined the call, the client had enabled CDC thinking that would “clean up the log”, but what that did in the immediate moment was fill up the log faster as it generated more transactions to update data in the CDC support tables.

So now the file was already at the 2 TB limit, meaning it couldn’t be grown further. But here’s the biggest problem: any other solution to reduce the log file size at this point would not work because…it would involve a logged transaction. And the log was full.

Possible solutions include:

• Disable CDC – that’s a logged transaction
• Add another log file – that’s also a logged transaction
• Declare it a disaster and restore the entire database from the most recent backups

The fix – kill another transaction and add another log file

We wanted to avoid restoring the database from backup, as that could mean further hours of downtime as well as more lost transactions. We determined the best possible solution was to try to Kill one of the smaller queries using the transaction log, and then quickly add another log file. It took several tries, but eventually we were able to kill one and add a second transaction log file, which allowed other transactions to start completing again.

Something like this:

BEGIN TRANSACTION;

/* Kill session 99 to release any locks/log space it may be holding */

 KILL 99;

/* Add a second log file to DatabaseName on a different drive */

ALTER DATABASE [DatabaseName]

ADD LOG FILE (

NAME = N'DatabaseName_log2'

, FILENAME = N'L: LogsDatabaseName_log2.ldf'

, SIZE = 64MB

, MAXSIZE = 2TB

, FILEGROWTH = 64MB);

 COMMIT TRANSACTION;

After we had the second log file we were able to monitor the progress for CDC and the drive space used by all the transactions recorded. This took a few hours but eventually caught up, and afterwards we emptied and removed the extra transaction log file and resized the original log file to reduce the massive amount of Virtual Log Files (VLFs). We also added a job to alert us in case the transaction log became more than 50% full to avoid another occurrence of this issue.

We were very fortunate, because had we not found a tiny windows to add another log file we would have had no choice but restore from backups. While you’re reading this, make sure your backups are actually ready for restores – check out our free tool, sp_CheckBackup to make sure.

The post SQL Server Log File Full at 2 TB Max with CDC: How We Recovered appeared first on SQL Server Consulting - Straight Path Solutions.

This month we have way more updates than in March, including recommendations from the Issues section of GitHub, so thank you to all who contributed!

We also have been working on the content pages referenced by the URLs in the stored procedures. We’ve been going through them all to make sure the content was more helpful. Lots of the previous content pages have had simple sentences that weren’t very descriptive, so we’ve been filling those out to provide more explanations.

This month the updates are mostly corrections, although there were additional checks added to sp_CheckBackup and sp_CheckTempdb.

We hope these new updates can help you, especially if you’ve never used these stored procedures. Here are the updates for April 2026, with links to the GitHub repositories where you can download the latest versions.

sp_CheckAG

• CORRECT omission of DTC Support check for SQL Server 2016
• CORRECT CPU configuration details (CheckID 113)
• CORRECT IP Address details for case sensitivity (CheckID 119)
• CORRECT check for recent events to account for AlwaysOn_health XE being stopped (CheckID 426)
• CORRECT incorrect logic for determining Seeding Mode
• ADD check for AlwaysOn_health XE being stopped  (CheckID 429)
• UPDATE check for Endpoint Owner to use SID in case sa login renamed (CheckID 406)
• UPDATE check for AG Owner to use SID in case sa login renamed (CheckID 407)
• UPDATE check for replica database not joined for clarity (CheckID 413)
• UPDATE check for session timeout to 2 checks – one at default, one below (CheckID 415)
• UPDATE check for offline listener to include IP and state (CheckID 417)
• UPDATE check for replicas not failover ready to include Server Instance (CheckID 421)
• ADD EndpointOwnerSID to Endpoints result set
• ADD AGOwnerSID to Availability Group result set
• CORRECT typos in CheckID 410, 415

sp_CheckBackup

• ADD EncryptionType column to @Mode = 2
• ADD CompressedBackupSizeInMB and CompressionPercent column to @Mode = 2
• ADD check for integrity checks (CheckID 503)
• ADD check for backup history not purged (CheckID 216)
• ADD check for high VLFs (> 200) (CheckID 217)
• ADD check for backups to NUL (CheckID 218)
• CORRECTED Check for password protected backups (CheckID 215)
• Corrected typo in CHECKID 211

sp_CheckSecurity

• CHANGE check for most recent version for SQL Server security updates
• CHANGE Issue, Details, and ActionStep data type in #Results to VARCHAR(MAX)
• CHANGE Failed Login check to suppress error message (CheckID 330)
• CHANGE Number of Error Logs check to suppress error message (CheckID 801)
• CHANGE Hide Instance check to suppress error message (CheckID 348)
• CHANGE Extended Protection check to suppress error message (CheckID 348)
• CHANGE Force Encryption check to suppress error message (CheckID 349)
• CORRECTED logic for creating #InvalidLogins table
• CORRECTED incorrect ActionStep for Contained Databases (CheckID 344)
• CORRECTED typos in ChecIDs 304, 305, 307, 310, 313, 314, 316, 321, 323, 324, 327, 330, 351, 622
• CHANGE CheckID 801 (error log retention is at default) to CheckID 622

sp_CheckTempdb

• ADD description of @Mode = 99 to @Help
• CORRECT usage of @Size in @Help
• CORRECT checks for Slow reads and Writes (CheckIDs 718 and 719)
• CORRECT redundant check for tempdb file with no growth allowed (CheckID 605)
• CORRECT redundant check for tempdb file with percentage growth (CheckID 711)
• CORRECT redundant check for tempdb file with growth < 64 MB (CheckID 712)
• CORRECT redundant check for tempdb file with high usage (CheckID 714)
• CORRECT logic for finding more than 8 cores (CheckID 707)
• REMOVED redundant code for @UsagePercent
• ADD code to avoid negative values for minimum @AvgReadStallMs and @AvgWriteStallMs
• ADD drop of #TraceFlg before it is created
• ADD check for more than 16 data files (CheckID 730)

The post Updates for all sp_Check tools – April 2026 appeared first on SQL Server Consulting - Straight Path Solutions.

The Investigation

The error message from Azure Managed Instance told the story right away: “The restore plan is broken because firstLsn (12345000000456700001) of log backup XXXXX is not equal to the lastLsn (12345000000123400001) restore point in time failed.” If you’ve worked with SQL Server backups, you know what the LSN (Log Sequence Number) is. It’s how SQL Server knows where the last backup left off and where to start the next one, so every transaction is captured. When those numbers don’t line up, SQL Server won’t let you restore, and for good reason.

My client had a process in place since they were running the migration, and we were there to catch them if needed. They were going to stop backups with their third-party backup tool, then use native SQL Server backups pointed to Azure Blob Storage to build their restore chain into Managed Instance. The plan made sense.

I quickly grabbed our trusty community tool sp_CheckBackup and ran this on the source:

SP_CheckBackup @Mode = 3, @DatabaseName = 'TheDBTHatIsErroringEvenWithTHeirPlan'

Mode 3 checks for split backup chains, backups going to different locations, anything that could complicate recovery. Even though they had that plan. this sure felt like a split backup chain… My gut was right. Some log backups were taken outside of the Blob Storage backup plan, after the initial full, differential, and logs. “Rogue Backups,” we call them at Straight Path (though sometimes it gets typoed to rouge backups – so we’ve started calling them by either name.)

Here’s what the timeline looked like:

• 12:00 PM – Full backup to Blob Storage (restored successfully)
• 6:00 PM – Differential backup to Blob Storage (restored successfully)
• 6:10 PM – Transaction log backup to Blob Storage (restored successfully)
• 6:20 PM – Rogue transaction log backup taken by the third-party backup tool (not in Blob Storage)
• 7:10 PM – Next scheduled log backup to Blob Storage (FAILED to restore, LSN mismatch)

That rogue backup at 6:20 PM was the problem. Even though the client had removed the database from their third-party backup policy, the backups didn’t actually stop running. That third-party log backup broke the chain that had been established in Blob Storage because it advanced the LSN past what our next Blob-based log backup expected.

The Fix

Stop the third-party backup solution entirely before initiating backups to Blob Storage. Don’t just remove the database from the policy. Actually confirm the backups have stopped. Run our free community tool, sp_CheckBackup to verify no rogue backups are sneaking in before you start your restore chain.

The Lesson

In this case, my client took a fresh full and differential during the migration activity and was eventually successful, but it was painful. And this was for a 1-2GB database. Imagine this with your 2TB or even 24TB database at GO LIVE. Quivers in chair.

Here’s what you should be doing if you’re planning a migration to Managed Instance (or any backup/restore migration):

1. Confirm all third-party backup tools are fully stopped, not just “removed from the policy.” Verify they are no longer touching the database. Run sp_CheckBackup to confirm.
2. Validate your backup chain before you start restoring. Use sp_CheckBackup @Mode = 3 to check for split chains and unexpected backup sources. If someone or something else took a backup you weren’t expecting, you want to know before you’re mid-migration, not after.
3. Bring your DBA team into migration planning early. With a little coordination on a planning call, gotchas like broken backup chains can be spotted before the big day. This one could have been solved immediately if we’d been on the call when it happened. And during cutover planning, we could have flagged the risk before it became a problem with a bit more involvement from the start.

Rogue backups are one of the most common issues we see across new client environments. Multiple tools taking backups of the same database, often without anyone realizing the other exists. Mike Walsh wrote about this exact pattern in SQL Server Backups and the Illusion of Safety, where he points out that when everyone is responsible for backups, sometimes no one is actually accountable for recoverability.

The Straight Path Team and Skills

Backup chain integrity is one of the first things we train any new DBA on at Straight Path. sp_CheckBackup is one of our free community tools, largely built by Jeff Iannucci and David Seis. I’m confident that anyone on our team would have done the same troubleshooting here. Backups and recoverability are DBA skills 101, and the majority of our clients perform routine restore testing and integrity checks to make sure data is safe and ready for when it matters most.

Straight Path Solutions is a team of nearly 20 SQL Server experts trusted by 120+ clients. We treat our clients’ environments as if they were our own because our job depends on your success. Making your life pain-free in the land of SQL is the rewarding part of our work. If you’re planning a migration, dealing with backup concerns, or just want to sleep better knowing someone’s watching your environment, reach out to us.

This post is part of our Case of the Week series, real SQL Server issues and lessons from the field.

The post SQL Server Case of the Week: A Broken Backup Chain Blocks Migration to Azure SQL Managed Instance appeared first on SQL Server Consulting - Straight Path Solutions.

But here’s the kicker: your CIO doesn’t care about page life expectancy. They care about data monetization.

The Problem: SQL Server Isn’t the Whole Playground Anymore

Once upon a time, uptime was the crown jewel. If the server was online, you were the hero. But now? Data is flowing into cloud warehouses like Snowflake and Databricks – maybe even Microsoft Fabric. Meanwhile, Marketing spins up SaaS apps faster than you can say “linked server.” And they’ve hired or subbed-out an entire analytics team that’s building Spark or Data Warehouse with Dashboards or Jupyter Notebooks that bypass you entirely.

And when those silos don’t talk to each other and the data doesn’t work for what they are doing? Guess who gets blamed. Yep, the DBA. You. Suddenly, you’re not the guardian of uptime; you’re the bottleneck on the road to AI progress or whatever Next Big Thing™ has your CEO’s ear.

The Pivot: Stop Being the Mechanic, Start Being the Architect

So what do you do? Sure, you can hunker down and work even harder on T-SQL and internals, but will that help? Think of it this way: Mechanics keep the engine running. Architects design solutions so that the engine powers the business.

In larger companies, the Chief Data Officer (CDO) role exists for one reason: to turn data into business value. But you don’t need a fancy title to start acting like one. What you do need is a strategy. That strategy is up-leveling your talents, and maybe bringing in some help.

But Code Though (Because You’re Still a DBA at Heart)

Let’s be honest: you’re not going to stop focusing on the servers and keeping everything up and running. But let’s take a look at a couple of queries to illustrate the mindshift you need. The first one is typical of a report from a monitoring tool. It says, “Hey boss, the server’s been up for 47 days.” You’ve shown your value – your systems are up and running when needed.  Except….

-- Old world: prove uptime
SELECT sqlserver_start_time
FROM sys.dm_os_sys_info;

That doesn’t mean anything to your Leadership. I’ve always said, unless you’re in a small company, people two levels above you have no idea what you do. So, how do you map the things you do to the things Leadership cares about?

Well, while the monitoring Dashboards you use are probably pretty useful, they don’t tell the boss why they should care about your work. A better approach is to map the result of your work to something that drives revenue for the company. I know that sounds marketing-y. Don’t make that face. This is what they care about.

How about this instead:

SELECT 
    s.sqlserver_start_time,
    COUNT(*) AS ‘CustomerPurchasesLast3Months’
FROM sys.dm_os_sys_info s
CROSS JOIN dbo.Customers c
JOIN dbo.Orders o ON c.CustomerID = o.CustomerID
WHERE o.OrderDate >= DATEADD(month, -3, GETDATE());

---------
sqlserver_start_time	CustomerPurchasesLast3Months
2025-09-01 08:15:00	12,345

This says, “Hey boss, here’s how many customers bought something in the last quarter on that server that I keep running for you.” Guess which one gets you invited to the strategy meeting with the Spark-ly people.

Be the Data Advocate

Being a “Data Advocate” is the new job security. The DBA who only cares about uptime is replaceable. The DBA who champions data as a business asset? That’s the one who probably sticks around, maybe even gets a promo from time to time. So the next time you’re tempted to brag about your deadlock troubleshooting skills, pause. Ask yourself: How is this data making the company money?

 That’s the straight path to data leadership.

We can help: CDO-as-a-Service

This is where we come in. Think of us as your “CDO-as-a-Service.”

• We handle the governance, the strategy, and the executive conversations.
• You stay focused on implementation, without getting bogged down in corporate politics.
• Together, we bridge the gap between “keeping it running” and “making it valuable.”

 It’s not about replacing your role. It’s about elevating it.

The post From “Keep it Running” to “Make it Valuable”: Why Your SQL Skills Aren’t Enough Anymore appeared first on SQL Server Consulting - Straight Path Solutions.