By Don Boxley, CEO and Co-Founder, DH2i (www.dh2i.com)
If you’ve ever tried to run SQL Server inside Kubernetes, you probably know that feeling – that slow burn of “wait, this should be easier.”
Kubernetes is amazing for stateless apps. Spin up, spin down, scale on demand. It’s all poetry in motion. But databases? They’re a different animal. They care deeply about where their data lives, and they don’t take kindly to pods that come and go.
The reality is, however, that more and more organizations are moving everything into containerized environments – including databases. Figuring out how to bring SQL Server along for the ride without losing the performance, reliability, and uptime that made you trust it in the first place, is the trick.
Step 1: Know What You’re Dealing With
For mission-critical data, SQL Server has always been a rock-solid choice. But in Kubernetes, that rock can feel a little heavy.
Here’s why: Kubernetes wasn’t originally built with stateful apps in mind. It likes things light and portable – microservices that don’t mind being shuffled around. SQL Server, on the other hand, wants roots. However, for when things go sideways, it needs stable storage, steady networking, and a safety net.
So… you end up wrestling with manual clustering, unpredictable failovers, and the occasional “why is my data suddenly missing?” moment when you drop SQL Server into a Kubernetes cluster without any special help.
Step 2: Let an Operator Handle the Boring Stuff
If Kubernetes had a “database whisperer,” it would be the Operator.
Think of an Operator as the extra set of hands that just gets your app. It knows what “healthy” looks like, it knows how to fix things automatically, and it can roll out updates without breaking everything.
The right SQL Server Operator can:
- Deploy and configure SQL containers the right way, every time
- Allow you to customize SQL Server AGs to your exact specifications
- Expedite your transition to simplified clustering and automatic failover
- Work with your CI/CD pipeline so updates don’t turn into chaos
It’s automation with instincts – something every DBA dreams about.
Step 3: Certification Isn’t Just a Sticker
It’s not just marketing fluff when you see that a SQL Server Operator is certified for Red Hat OpenShift.
It tells you that the solution has passed a gauntlet of real-world tests – everything from integration, performance, security to compatibility with OpenShift’s latest release. It is essentially Red Hat telling you directly, “Indeed, this one plays well with the rest of the family.”
That means for you, less troubleshooting, fewer late-night Slack pings, and the confidence that your database layer won’t crumble during the next upgrade cycle.
Step 4: Time to Go All-In on Cloud-Native Thinking
Once you’ve got the right Operator, the next step is adopting a more modern mindset. Forget the old “build a monolith and pray” model. Today, we think in terms of agility, modularity, and automation.
A few best practices worth stealing:
- Use a Sidecar Setup
Run SQL Server and its companion clusterware in separate containers inside the same pod – it keeps updates clean and your sanity intact - Go Declarative
Use YAML files to tell Kubernetes what you want the system to look like – it’ll handle the how - Automate Failover
Manual failovers are fine for the lab, but not for production – make sure your operator is taking you to an HA framework that detects and recovers from issues in seconds
- Secure Everything
If your SQL cluster spans clouds or regions, wrap it in encrypted tunnels or use software-defined perimeters (SDP) – and sleep better
Step 5: Stretch It Safely
Once SQL Server is running comfortably in containers, you can start thinking bigger. You might want hybrid setups with one foot on-prem and the other in the cloud, or, you might need to stretch clusters across regions for disaster recovery.
That is all made possible with modern Kubernetes Operators and container-ready high availability solutions. All while keeping your data synchronized and protected, you can create Availability Groups (AGs) that span clouds, regions, and even continents.
Step 6: Treat Your Database Just Like the Rest of Your Apps
Here’s where a lot of teams trip up: they modernize everything except the database. SQL Server ends up as the sacred cow – stable, yes, but stuck in time.
That doesn’t work anymore. Today, databases can (and should) live inside your DevOps loop – i.e., patch them, test them, version them. Then, automate as much as possible. And of course, watch performance metrics and failover speeds the same way you’d monitor uptime for a frontend service.
The smoother everything runs the more you treat your database like part of the app ecosystem, not an outsider.
Running SQL Server on Kubernetes and OpenShift used to sound like a bad idea…
Now, it’s a best practice, as long as you approach it thoughtfully.
Get a certified Operator. Follow cloud-native patterns. Automate relentlessly with modern HA technology. And remember this, above all, this isn’t just about containers, it’s about freedom. The freedom to run your data where you want… and, how you want… without giving up uptime, performance or peace of mind.
You’ll wonder how you ever managed without it when that moment finally clicks, that is, when SQL Server stops fighting Kubernetes and starts thriving in it.
##
ABOUT THE AUTHOR
Don Boxley Jr is a DH2i Co-founder and CEO. He has more than 20 years in management positions for leading technology companies. Boxley earned his MBA from the Johnson School of Management, Cornell University.
