Run Microsoft SQL Server
on Kubernetes
SQL Server on Kubernetes means running Microsoft SQL Server in Linux containers from Microsoft's official image, with Kubernetes scheduling the pods and attaching their persistent storage. Microsoft has supported SQL Server containers on Kubernetes since SQL Server 2017, and SQL Server 2025, 2022, and 2019 all run this way. Kubernetes has no Windows Server Failover Cluster, so an operator takes over Always On availability group failover, backups, and upgrades.
Solanica Platform deploys and operates SQL Server on any Kubernetes cluster, in the cloud or in your own data center. Failover, backups and upgrades are automated. Built on the open-source OpenEverest project.
What it costs
A typical production setup: 16 vCPU, 64 GB RAM, 1 TB of storage and a high-availability replica. Here is the same workload on Azure SQL Managed Instance and on Kubernetes with Solanica.
Azure SQL Managed Instance
General Purpose tier, pay-as-you-go
SQL Server on Kubernetes with Solanica
Your cluster, your SQL Server licenses
No cloud lock-in
Azure SQL, Amazon RDS and Cloud SQL each tie SQL Server to one provider. With Solanica, the same deployment runs on any Kubernetes cluster.
Any Kubernetes cluster
AKS, EKS, GKE, OpenShift, Rancher or upstream Kubernetes on-premises. The manifests are the same everywhere, so moving between environments doesn't mean rewriting your tooling.
Standard formats and tools
Backups go to S3-compatible storage you control and metrics go to Prometheus. Your DBAs keep using the SQL Server tools they already know.
Your licensing choice
Bring existing licenses through Software Assurance, use Developer Edition for dev and test, or Express for small workloads. How licensing works on Kubernetes.
Open source underneath
The platform is built on OpenEverest, an open-source set of Kubernetes operators for databases. You can read the code and run it yourself.
How it works
You describe the database you want as a single Instance in OpenEverest. The mssql provider creates the SQL Server resources in your cluster and keeps them in the state you declared. Read more in the MSSQL Provider and MSSQL Operator docs.
What's included
The operations you would expect from a managed SQL Server service, running in your own cluster.
High availability
Always On availability groups managed by the operator, with automatic failover and synchronous or asynchronous replicas.
Read the docs →Backup and restore
Scheduled full, differential, and log backups to S3-compatible storage, with point-in-time restore.
Read the docs →Monitoring
SQL Server metrics exported to Prometheus, with Grafana dashboards and alerts for replication lag and resource usage.
Read the docs →Security
TLS for client connections, Kubernetes RBAC and network policies, and credentials kept in Kubernetes Secrets or an external vault.
Read the docs →Always On availability groups on Kubernetes
Kubernetes has no Windows Server Failover Cluster, so the Solanica operator takes over the job of deciding when to fail over. It's built so that a failover never loses a committed transaction.
How failover works
- Standard availability groups. The operator builds a regular Always On availability group with CLUSTER_TYPE = EXTERNAL, certificate-secured endpoints, and automatic seeding.
- Fast, reliable detection. A sidecar in each pod reports the replica's role and renews a Kubernetes Lease while it's primary. It also runs sp_server_diagnostics, so a frozen primary is caught, not just a crashed one.
- No data-losing failovers. Only a synchronized secondary is promoted. A forced failover that could lose data stays off unless you turn it on.
- Planned events hand over first. Node drains and rolling upgrades move the primary role to a healthy secondary before the old primary pod stops.
- Traffic follows the primary. One Service always points at the primary for writes, and another at the readable secondaries for reporting.
- Start small, grow later. A standalone instance can be converted to an availability group in place, keeping its databases.
SQL Server on VMs vs Kubernetes
How an Always On availability group runs on virtual machines compared with Kubernetes and the Solanica operator.
| SQL Server on VMs | SQL Server on Kubernetes with Solanica | |
|---|---|---|
| Who decides to fail over | Windows Server Failover Clustering on Windows, Pacemaker on Linux | The Solanica operator, with a Kubernetes Lease electing the primary |
| Availability group cluster type | WSFC on Windows, EXTERNAL on Linux | EXTERNAL |
| How applications connect | An availability group listener that the cluster moves to the primary | A Kubernetes Service that follows the primary, and another for readable secondaries |
| Planned maintenance | Fail over by hand, node by node, from a runbook | Node drains and rolling upgrades hand the primary role to a synchronized secondary first |
| Replacing a failed replica | Build a VM, install SQL Server, join it to the cluster and the availability group | Kubernetes reschedules the pod and the operator brings it back into the availability group |
| Configuration | Per-VM setup, cluster wizards, and scripts | One declarative resource you can keep in Git |
| Cross-region disaster recovery | Multi-subnet clusters, distributed availability groups, or log shipping | Restore backups in the second region |
| Licensing | License the VM's virtual cores | License each container's cores, minimum four, or the worker VM's cores |
Each availability group runs inside one Kubernetes cluster. Cross-region disaster recovery currently means restoring backups in the second region.
SQL Server 2025 support
New instances run SQL Server 2025 by default. SQL Server 2022 and 2019 are supported too, so you can move existing databases first and upgrade them later.
The 2025 engine
SQL Server 2025 adds a native vector data type for AI and similarity search, a native JSON type, and regular expressions in T-SQL. It runs from Microsoft's official Linux container image, the same engine as on Windows.
A bigger Standard edition
In 2025, Standard edition can use up to 32 cores and a 256 GB buffer pool, up from 24 cores and 128 GB in 2022. Express databases can grow to 50 GB. Many workloads that needed Enterprise for headroom now fit on Standard.
Upgrades without surprises
Each version is pinned to a tested cumulative update, so a pod restart never pulls a different build. In an availability group, upgrades roll through the secondaries first, then hand the primary role to an upgraded one. Downgrades, which SQL Server can't do, are blocked.
| Version | Status | Native backups to S3 and point-in-time restore | Contained availability groups |
|---|---|---|---|
| SQL Server 2025 | Default for new instances | Yes | Yes |
| SQL Server 2022 | Supported | Yes | Yes |
| SQL Server 2019 | Supported | No, the engine can't write to S3 | No |
How 2025 became the default, and how point-in-time recovery works →
SQL Server licensing on Kubernetes
Licenses are usually the largest line in a SQL Server budget, and the rules for containers are rarely explained in one place. This is how Microsoft's rules apply on Kubernetes.
License the container or the node
- Per container: one core license for each virtual core given to the container, with a minimum of four per container.
- Per worker VM: with Software Assurance or subscription licenses, license the VM's virtual cores and run any number of SQL Server containers on it.
- Per physical host: license every physical core with Enterprise edition. With Software Assurance or subscriptions, that covers unlimited containers.
Passive replicas are free with SA
With Software Assurance or subscription licenses, each licensed primary covers one passive replica for high availability, one for disaster recovery, and one more for disaster recovery in Azure. Passive means it serves no queries: only consistency checks, backups, and monitoring. Readable secondaries need their own licenses.
Running on EKS, GKE, or another cloud
- License Mobility through SA lets you move licenses to an authorized partner's shared servers, such as AWS or Google Cloud nodes, at most once every 90 days.
- The Flexible Virtualization Benefit lets licenses with SA or subscriptions run on any other provider's servers. It excludes the Listed Providers, including AWS, Google Cloud, and Alibaba.
- Licenses without SA can't be used on shared public cloud servers at all, and subscription licenses bought through the Microsoft Customer Agreement don't include License Mobility.
Pick the edition for the job
- Developer is free for every non-production environment and has all Enterprise features.
- Express is free in production, for databases up to 50 GB in 2025, without availability groups.
- Standard supports basic availability groups only: two replicas, one database each, no readable secondary.
- Enterprise is needed for three or more replicas and readable secondaries.
Pay-as-you-go billing through Azure Arc isn't available for SQL Server in containers.
A three-replica availability group of 8-core containers, licensed with Enterprise edition and Software Assurance: a primary, a synchronous secondary for automatic failover, and an asynchronous secondary for disaster recovery. With both secondaries passive, you license 8 cores. Make both secondaries readable for reporting and it's 24 cores.
A summary of Microsoft's SQL Server licensing guide, not licensing advice. Your agreement and Microsoft's Product Terms govern. We review licensing with you as part of every assessment.
Learn more
Deep dives from the engineers who build the SQL Server operator.
Running SQL Server on Kubernetes
Availability groups without a Windows cluster, memory and licensing-aware sizing, native backups to S3, and a comparison of SQL Server operators.
Read the whitepaper → BlogChaos Testing SQL Server Availability Groups on Kubernetes
Pod deletes, node drains, hard kills, and network partitions against a live availability group, and what we fixed along the way.
Read the post → BlogSQL Server 2025 by default, and point-in-time recovery
Why 2025 is the new default, and how backup chains are assembled to restore to a precise moment.
Read the post → BlogBringing Microsoft SQL Server to Kubernetes
How the operator and the OpenEverest provider are built: custom resources, Lease-based failover, and native backups.
Read the post → ComparisonSolanica vs Azure SQL Managed Instance
Where each runs, failover, backups and portability, licensing, and where Managed Instance is ahead.
See the comparison →SQL Server on Kubernetes: frequently asked questions
Can you run SQL Server on Kubernetes?
Yes. SQL Server has run on Linux since SQL Server 2017, and Microsoft publishes official container images at mcr.microsoft.com/mssql/server. On Kubernetes, each SQL Server instance runs as a pod with a persistent volume, and an operator handles availability groups, backups, and upgrades. SQL Server 2025, 2022, and 2019 all run on Kubernetes.
Is SQL Server officially supported on Kubernetes?
Yes. Microsoft supports SQL Server on Linux containers on Kubernetes and OpenShift. Microsoft supports the SQL Server engine and its container image. The Kubernetes distribution is supported by its vendor, and the operator that manages failover is supported by whoever ships it. With Solanica Platform, that's our team.
How does SQL Server licensing work on Kubernetes?
You license either each container or the nodes it runs on. Per container, you need one core license for each virtual core given to the container, with a minimum of four. With Software Assurance or subscription licenses, you can instead license a worker VM's virtual cores and run any number of SQL Server containers on it, and each licensed primary covers one passive secondary for high availability and one for disaster recovery, as long as they serve no queries. Developer edition is free for every non-production environment. See the licensing rules for containers.
How do availability groups on Kubernetes differ from availability groups on VMs?
The SQL Server feature is the same: replicas, synchronous or asynchronous commit, automatic seeding, and readable secondaries. What changes is who decides to fail over. On Windows VMs that's Windows Server Failover Clustering, and on Linux VMs it's Pacemaker. On Kubernetes, the availability group uses CLUSTER_TYPE = EXTERNAL and an operator takes that role. Solanica's operator detects failure with sp_server_diagnostics, elects the primary with a Kubernetes Lease, promotes only a synchronized secondary, and moves a Kubernetes Service to the new primary instead of using a listener. Read how it works in the whitepaper.
Which SQL Server versions can run on Kubernetes?
On Solanica Platform, SQL Server 2025 is the default for new instances, and SQL Server 2022 and 2019 are supported too. Native backups to S3 with point-in-time restore, and contained availability groups, need SQL Server 2022 or later.
Can you do point-in-time recovery for SQL Server on Kubernetes?
Yes. The operator takes native full, differential, and transaction log backups straight to S3-compatible object storage, with log backups every 5 minutes by default. To restore, it rebuilds the full, differential, and log chain and stops at the moment you choose with STOPAT. This needs SQL Server 2022 or later. How point-in-time recovery works.
Which SQL Server features don't work in Linux containers?
SQL Server on Linux doesn't support FILESTREAM and FileTable, merge replication, linked servers to databases other than SQL Server, or the CmdExec, PowerShell, and SSIS job steps in SQL Server Agent. Features that depend on Azure Arc, including Microsoft Entra ID authentication, aren't available in containers. Check your databases for these before you move them.
How does SQL Server on Kubernetes compare to Azure SQL Managed Instance?
Azure SQL Managed Instance is a fully managed service that runs only in Azure, with the license included in the price or covered by Azure Hybrid Benefit. With Solanica Platform, SQL Server runs on Kubernetes clusters you operate, in any cloud or on-premises, on your own licenses, and backups are standard SQL Server files in your own object storage. See the full comparison.
From pilot to production
Our engineers work with your team from the first cost estimate to running in production.
Assessment
We look at your current SQL Server estate and licensing, and estimate what it would cost to run on Kubernetes.
Pilot
You deploy on your own cluster, move a real workload over, and test failover, backups and monitoring against your requirements.
Production
We help you roll out with a repeatable setup that fits your GitOps workflow, and our team stays on hand for support.
Talk to us about your SQL Server workloads
Tell us about your setup and we will connect you with the engineers who build and support the platform.