Dealing with the challenge of creating a unified SQL Server data estate [Q&A]

Many organizations are running SQL Server across Windows, Linux, containers, and Kubernetes. Obviously there are advantages if that environment can be unified into a single data estate, but doing so presents a number of challenges.

We spoke to Don Boxley, CEO and co-founder of DH2i, to look at the problems involved and how to address them.

BN: Why is unifying the SQL Server environment so hard?

DB: Most teams inherit a patchwork of choices that were right at the time but do not play nicely together. Each platform brings different tools, different operational muscle memory, and different failure modes. That creates silos, duplicated effort, and a lot of challenges around resiliency. The business feels it as slower delivery and higher risk of downtime.

Unification is really about giving teams one way to manage, protect, and move SQL Server wherever it lives. The platform stops being the constraint when you can apply a single high availability and management strategy across Windows, Linux, and Kubernetes. From a cost, performance, and compliance standpoint, you get freedom to place each workload where it makes the most sense.

BN: How ready are SQL Server on Linux and in containers for true production?

DB: They are ready now. The same core SQL Server engine enterprises trust on Windows runs on Linux with the same update and security cadence. We see production deployments today in finance, healthcare, and SaaS, with organizations choosing Linux for its footprint, automation toolchains, and skills alignment.

Containerized SQL Server adds another level of speed and portability. If you already operate Kubernetes, you can standardize deployment and lifecycle, then layer in the right database-aware availability. The headline is choice. You do not have to pick a single operating system or deployment model to be enterprise grade.

BN: Organizations already juggle SQL Server across Windows, Linux, and containers. What’s missing to really bring it all together?

DB: The big gap is consistency. Right now, most teams have one way of handling availability on Windows, another on Linux, and maybe a third in containers. That patchwork works… until something goes wrong. What people really need is a single approach to keep SQL Server highly available no matter where it’s running. That way you don’t have to retrain staff or reinvent your recovery plan every time the platform changes.

Networking is another pain point. Stretching clusters across data centers or clouds often requires setting up complicated VPNs or opening ports, which introduces security vulnerabilities. In order to put workloads where they make the most sense without waiting on network rewiring, what folks are really looking for is a simpler, secure way for nodes to talk to each other across environments

BN: Kubernetes already improves reliability. Why isn’t that enough?

DB: Kubernetes is terrific at keeping the plumbing running. If a pod crashes or a node goes down, it’ll bring it back up somewhere else. However, its built-in failover technology is accompanied by inherent latency that is in no way, shape, or form ready for the strict uptime requirements necessitated in critical industry. Additionally, Kubernetes doesn’t really understand the state of SQL Server itself. It can’t tell you if an availability group is in quorum or whether a replica is safe to promote. That’s not its job.

That’s why you need something on top that speaks the language of databases. Health checks, fast automated failovers, and the assurance that what’s being promoted is actually consistent is the data layer protection that SQL Server needs. In other words… Kubernetes protects the container, but you still need something to protect the data inside it.

BN: SQL Server 2025 is introducing native vector support. What does that unlock, and how should leaders prepare?

DB: The vector support is exciting because it lets you build AI-driven apps -- things like semantic search or retrieval-augmented generation -- directly inside SQL Server. You don’t have to spin up a separate database just to manage embeddings. That simplifies architecture and makes life easier for teams who already know SQL Server.

But once those workloads are powering real apps, the spotlight shifts to availability. If your vector store goes down or drifts out of sync, your AI experience breaks. Leaders need to plan for the same kind of bulletproof failover and continuity they’ve always demanded from their core transactional systems. AI doesn’t get a free pass -- it has to be just as reliable.

BN: What deployment patterns are you seeing as organizations try to unify estates?

DB: A lot of teams are taking a hybrid approach. They leave core Windows workloads where they are, but new projects often go to Linux or containers because they’re easier to automate. Kubernetes gives them a common way to deploy across all of it. What ties it together is an availability strategy that lets workloads failover seamlessly across platforms and locations.

We’re also seeing more organizations push for cloud neutrality. Instead of betting everything on one provider, they spread workloads across regions or even multiple clouds. The trick is making sure SQL Server stays continuous no matter where it’s running. That takes smarter networking and infrastructure-agnostic failover, not just brute force duplication.

BN: What would be your one piece of advice for IT leaders starting this journey?

DB: Don’t let the platform box you in. Start by defining one playbook for how you’re going to keep SQL Server available and recoverable, and then decide later whether a workload belongs on Windows, Linux, or Kubernetes. That way you’re making well-reasoned business decisions, not technology-forced ones.

So finally, once you’ve got that playbook, you need to test it. Make sure the team knows what to do in both planned and unplanned scenarios -- for instance, run through failovers and patch clusters to ensure the technology meets your unique uptime needs. Availability stops being a fire drill and becomes muscle memory, when everyone’s practiced.

Image credit: tonsnoei/depositphotos.com