SQL Server Licensing is Simple

Question

SQL Server Licensing is Simple

Steve Jones - SSC Editor

SSC Guru

Points: 740221
More actions
December 3, 2025 at 12:00 am

#4693012

Comments posted to this topic are about the item SQL Server Licensing is Simple, which is is not currently available on the site.

Viewing 11 posts - 1 through 11 (of 11 total)

You must be logged in to reply to this topic. Login to reply

jasona.work SSC Guru Points: 50239 More actions · Answer 1

Way back in the day, a couple years after I started my present job, I had to manage the Oracle database we had until they found a new Oracle DBA. They asked me to look into the licensing for Oracle so they could move it off of a couple dedicated servers and into the VMWare system.

Yeah, once I came across the restriction in Oracle licensing that, if you virtualize your Oracle database on any hypervisor other than Oracles' own hypervisor, you had to license it for every possible host and every possible core it could land on, that drove the cost up well past what they were willing to pay for it.

It didn't take long (comparatively) after that for us to tell the developers "we're no longer going to be supporting Oracle, either migrate your databases to SQL Server, or find a new place to host them on Oracle." Now, we no longer have Oracle.

David.Poole SSC Guru Points: 76319 More actions · Answer 2

I now know why it is called a software tax.

Apparently, the UK tax code runs to 10s of thousands of pages. There are tax accountants and specialist companies to help with taxes. Years ago, HMRC ran an advertising campaign to say that "Tax doesn't have to be taxing!" and yet it obviously is complex enough to support an ecosystem of professions.

It strikes me that if there is a complex set of licensing rules, then there are huge costs for everyone.

Legal teams putting the licensing in place
Legal teams for customers trying to interpret how licenses apply to them
Auditing teams on both sides to determine if customers are sufficiently licensed or in breach
Finance staff on both sides, billing and paying
Legal staff prosecuting/defending disputes

None of that huge cost delivers a line of code.

LinkedIn Profile

Steve Jones - SSC Editor SSC Guru Points: 740221 More actions · Answer 3

David.Poole wrote:

...
None of that huge cost delivers a line of code.

Same could be said of health insurance in the US.

I miss the days of buying an installed copy of software and owning it (or appearing to own it)

David.Poole SSC Guru Points: 76319 More actions · Answer 4

jasona.work wrote:

Yeah, once I came across the restriction in Oracle licensing that, if you virtualize your Oracle database on any hypervisor other than Oracles' own hypervisor, you had to license it for every possible host and every possible core it could land on, that drove the cost up well past what they were willing to pay for it.

On my 1st Big Data project, our POC was running fine, was scalable, and impressed everyone who saw it.

It didn't impress the architects. "We are an Oracle shop. What Oracle products are you using?" they asked. We didn't need any; none of it was applicable or relevant. The architects insisted on our using Oracle ODI. The licensing terms at the time were that, even though ODI was a SQL generator, you had to license it on every core on every node of the source and target. Our Big Data solution used Spark on Hadoop. ODI was a product we didn't need at a price we couldn't afford, inflicted on us due to corporate politics.

The thing with Oracle ODI is that it was one of the better ETL tools. Oracle is one of the Big 3 for databases for solid technical reasons. Their licensing regime feels like corporate well poisoning.

LinkedIn Profile

Alfredo Giotti Ten Centuries Points: 1218 More actions · Answer 5

Steve,

I appreciate the write-up, but I have to push back on the idea that SQL Server licensing is “simple.” That’s a bit like saying jumping out of a plane is easy because gravity does most of the work. Technically true… until you look at everything that actually matters.

Counting cores is the easiest part of SQL licensing.

It’s the other 95% of operational reality that turns it into a full-time job — and in many organizations, an entire ecosystem.

Here’s what “simple” really looks like in practice:

Licensing physical hosts vs licensing VMs
Tracking VM mobility and making sure licensing remains compliant after every vMotion
HA/DR rules (which magically change depending on edition, SA status, and deployment pattern)
Passive node rights — but only if they meet a set of criteria that reads like the DMV handbook
Unlimited virtualization rights with SA — unless something moves, expires, or someone forgets to document it
DR-only instances that count as “free” until Microsoft changes its interpretation the following year
Version/edition eligibility, downgrade rights, and historical SA coverage trails
Hybrid cloud licensing, Cloud Solution Provider (CSP) rules, subscription-based entitlements
Licensing drift as engineers spin up new servers without telling anyone
Compliance lineage to satisfy audit teams who absolutely do believe SQL licensing is complex
Data-quality gaps that turn those neat theoretical licensing diagrams into a detective investigation
Mapping host-level core counts to instance-level licensing classifications, then reconciling it with what the business thinks they bought

Compared to Oracle’s core-factor nightmare? Sure — SQL looks like the “easy sibling.” But in the real world? Where environments change daily and you need airtight auditability?

SQL Server licensing is far from simple. It’s just complex in different, more subtle ways — the kind that actually impact compliance risk, operational planning, and financial forecasting.

So yes, Oracle may require a PhD and a support group…

But SQL licensing is not a “choose an edition and count to 16 cores” activity either.

Happy to compare real-world scenarios anytime — because the distance between the brochure version of SQL licensing and the actual enterprise implementation is about the same distance between a recruiting poster and Marine Corps boot camp.

jasona.work SSC Guru Points: 50239 More actions · Answer 6

David.Poole wrote:

On my 1st Big Data project, our POC was running fine, was scalable, and impressed everyone who saw it.
It didn't impress the architects. "We are an Oracle shop. What Oracle products are you using?" they asked. We didn't need any; none of it was applicable or relevant. The architects insisted on our using Oracle ODI. The licensing terms at the time were that, even though ODI was a SQL generator, you had to license it on every core on every node of the source and target. Our Big Data solution used Spark on Hadoop. ODI was a product we didn't need at a price we couldn't afford, inflicted on us due to corporate politics.
The thing with Oracle ODI is that it was one of the better ETL tools. Oracle is one of the Big 3 for databases for solid technical reasons. Their licensing regime feels like corporate well poisoning.

Because of some data connections a few of our apps require, we have to load the Oracle Data Access Components on a couple servers to create linked servers. So far, Oracle hasn't turned that into a "pay us" product, but I suspect the day they do we're going to tell the developers of the apps in question "figure out another way to get that data."

I'll grant that by using the "xCopy" versions and making sure to keep a copy of the tnsnames file, it's not too hard to get it set up so SQL uses it. It's the ONE connection that requires a certificate-based login to the Oracle database on the other end that gives me fits...

Steve Jones - SSC Editor SSC Guru Points: 740221 More actions · Answer 7

David.Poole wrote:

jasona.work wrote:

Oracle is one of the Big 3 for databases for solid technical reasons. Their licensing regime feels like corporate well poisoning.

Yep, it's a wild thing. They get devs or DBAs to use a tool because it works well. Then they want $$$$$$

Steve Jones - SSC Editor SSC Guru Points: 740221 More actions · Answer 8

Alfredo Giotti wrote:

Steve,
I appreciate the write-up, but I have to push back on the idea that SQL Server licensing is “simple.” That’s a bit like saying jumping out of a plane is easy because gravity does most of the work. Technically true… until you look at everything that actually matters.
Counting cores is the easiest part of SQL licensing. It’s the other 95% of operational reality that turns it into a full-time job — and in many organizations, an entire ecosystem.
...
Happy to compare real-world scenarios anytime — because the distance between the brochure version of SQL licensing and the actual enterprise implementation is about the same distance between a recruiting poster and Marine Corps boot camp.

Fair points, and if you have mobility and non-SA, it can be weird. I run into so many people, however, that don't do those things. They get instances set to certain VMs, esp post-Broadcomm/VMWare, and they have SA. I get that it might be different for some of you, but in my past, which had the introduction of managing the virtualized SE/EE rules, it felt much simpler than Oracle.

That being said, I'd love to see someone write up their experiences as guidelines with scenarios. If you're interested, this would be a great article. And I'd pay you 😉

Alfredo Giotti Ten Centuries Points: 1218 More actions · Answer 9

Steve,

Thanks for the thoughtful reply — I really appreciate it. You make a fair point: in many environments where SA is consistently maintained, VM mobility is limited, and deployments remain relatively static, SQL Server licensing does feel more predictable and far less chaotic than what you see in the broader enterprise space. In those cases, the rules behave, the diagrams stay clean, and life is good.

Where things tend to become more nuanced is in larger or more dynamic organizations. Once you introduce hybrid architectures, mixed entitlement types, HA/DR layering, frequent VM mobility, DR activation, CSP usage, and the occasional data-quality mystery, the practical side of SQL licensing often drifts quite far from the tidy theoretical model. That disconnect — between documented rules and lived reality — is what drives much of the operational complexity.

Your suggestion about documenting real-world scenarios is a good one. There’s a significant gap between Microsoft’s high-level guidance and the practical edge cases that teams routinely run into. I’ve encountered enough of those scenarios over the years that I could certainly contribute something meaningful. If you’re serious about collaborating, I’d be glad to explore what a structured set of guidelines could look like.

Thanks again for the engaging discussion. It’s always valuable when people can compare experiences from different angles — especially in areas where so many teams quietly struggle.

Best regards,

Fred

Steve Jones - SSC Editor SSC Guru Points: 740221 More actions · Answer 10

You are welcome and thanks for replying. If you want to draft something, feel free to submit (write for us above) or email me: sjones at this domain.