Sql Server Licensing & Differences

Hi Friends, as we’ve already discussed about various Sql server versions and editions, it’s time to discuss about various sql server licenses available and what the difference among those is.

You can check various Editions here.

There are two type of licensing options available with Sql server 2012:

  1. Core based licensing
  2. Server+CAL licensing model

Core Based Licensing

Physical Machine:

In previous versions, sql server licenses were based on per processor based. Means if you are having one processor and this processor is having two cores then one license is enough to meet your needs.

But this is not the case in Sql 2012. Now we have core based licensing. That means if we are having a processor with 2 cores then we’ll need 2 Sql licenses.

Core-based licenses are sold in two-core packs with a minimum of 4 core licenses required for each physical processor. This means that at a minimum you need to purchase two of these two-core packs for each physical processor occupying a processor socket.

Below is the matrix for license required according to cores. We know that 2 double core license is minimum purchase so one will have to purchase license for 4 cores at minimum. As number of cores increases, number of sql server licenses also increase accordingly.

You can notice, even if you license a single or dual core processor, you still have to buy enough two-core packs to license the minimum of four cores. With this four-core minimum license per physical processor requirement of SQL Server 2012, it makes more sense to have a single four-core processor than two dual-core processors.

The Per Core licensing option allows for unlimited users or devices to access SQL Server (both internally and externally). The major benefit of this option is that there is no requirement to try to quantify the number of users or devices accessing the SQL Server, be that direct or via indirect means using in between layers e.g. business logic layer.

Only Enterprise and Standard Editions of SQL Server 2012 are available for core-based licensing. 

Virtual Machine:

Let’s discuss how licensing will be required for virtual machines. Each virtual machine is treated as different machine and each core in these virtual machines will be considered as separate core.

Let’s take an example of one server:

These is one server. This server is having 2 VMs. One VM is having 2 Cores and second VM is having 6 cores.

  • Server-1
    • VM-1
      • Core-1
      • Core-2
    • VM-2
      • Core-1
      • Core-2
      • Core-3
      • Core-4
      • Core-5
      • Core-6

Now we know that for VM-1 we need sql server licenses for 2 cores but we know that we need to purchase minimum two 2-core packs i.e. we need to purchase licenses for 4 cores minimum.

So for VM-1 we need 4 sql server licenses.

In same way we need three 2-core packs for VM-2 which will give us 6 licenses. So to cover both VMs we need 10 licenses i.e. five 2-core packs licenses. 

Host server or server farm core licensing:

The total number of cores available on a host server or server farm can be licensed to maximize virtualization capabilities and take advantage of full computing power. To fully license a host server or server farm, Enterprise Edition core licenses along with Software Assurance are required.

There are different type of volume licencing options available:

Open Value License Program is the recommended program if you have a small to midsize organization with five or more desktop PCs and want to simplify license management, manage software costs, and get better control over your investment.

Open License Program is a Microsoft service that allows corporate, academic, charitable, or government organizations to obtain volume licenses for Microsoft products. It is ideally suited for companies with between 2 – 250 personal computers, but can accommodate organizations with up to 750 computers.

Select License Program was designed specifically for medium and large organizations with 250 desktop PCs or more that have mixed software requirements and want a simple, flexible, and affordable way to purchase the latest Microsoft technology on a “pay as you go” basis.

EA/SA (Enterprise Agreement/Software Assurance) Program is a volume licensing package offered by Microsoft. It primarily targets large organizations that have 500 or more personal computers. 

This type of licensing allows for an unlimited number of virtual machines and allows dynamic provisioning and de-provisioning of virtual processors.

Server + CAL Licensing

Physical Machine:

As name specified, in this model there will be one server license for server which will host Sql server. CAL is client access license which will be required for each and every user who is trying to connect to the Sql server.

These users may be connecting to Sql server directly by application installed on their desktops or these user can give call to any intermediate layer and this intermediate layer intern connect to the server. In both the cases same number of CALs are needed.

Now question may arise, why we need this licensing model.

The Server + CAL option is often the preferred licensing option when:

  1. Smaller SQL Server implementations exist and SQL is the supporting database for another application or smaller Intranet; and
  2. The number of users or devices accessing SQL Server can be quantified and Server + CAL is more cost effective than the Per Core model

Server + CAL Licensing for SQL Server 2012 is only available for the Standard and Business Intelligence Editions. Users need a CAL that is the same version or newer than the version of the licensed SQL Server they need to access. A SQL Server 2012 CAL can be used to access multiple licensed SQL Servers, including SQL Server 2012 Standard and Business Intelligence Editions. These new CALs can also be used for previous versions of SQL Server, including the Enterprise Editions of 2008 and 2008R2, for which the Server + CAL licensing model was still available.

Virtual Machine:

Now let’s discuss how Server+CAL licensing will be required for virtual machines. In this case also each virtual machine is treated as different machine but licenses are required for each VM, not for each core.

Let’s take above example once again:

These is one server. This server is having 2 VMs. One VM is having 2 Cores and second VM is having 6 cores. There are 20 users who are accessing these servers.

  • Server-1
    • VM-1
      • Core-1
      • Core-2
    • VM-2
      • Core-1
      • Core-2
      • Core-3
      • Core-4
      • Core-5
      • Core-6

So now there will be 2 sql server licenses required for both VMs. And 20 CALs are required for users who are accessing these servers.

Below is the matrix which shows which license is available with which edition.


Server + CAL

Core Based




Business Intelligence






Now you can think from your organization’s perspective, which one suite you.



SQL Server Downgrades – Rules & Restrictions

Hello Friends, Today we will discuss about rules according to which Sql server downgrades are possible. Like upgrades, these operations can be edition specific or version specific.

What is the need to downgrade?

But what is the need to downgrade? Well there is. Let’s say you have an application which is working fine with current edition\version of Sql server and then you decided to upgrade to new edition\version. You upgraded your database edition\version and then you saw that there are many issues exposed which could be new features related to security, availability etc. of new edition\version. And your application is not ready to handle those features without additional work.

Now to get things working, you’ll have to downgrade your Sql edition\version back to previous one and then decide upon the strategy to follow for future.

Again it is not possible to downgrade any edition, version without any rules or restrictions. There are some set of rules.

Let’s see how this works.

Edition Downgrades

If we want to downgrade Sql server edition then we need to first uninstall the higher edition and then install the lower edition of Sql server. There is no standard tool which can provide this downgrade out of the box. Uninstallation is the only option.

Now we may have few databases which were there in higher editions. What about those databases?

There are following steps to get these databases working on lower editions:

  1. To get those databases in lower editions, first we need to check if these databases are using any higher version specific features or not. A database created in SQL Server 2012 Enterprise Edition that uses enterprise edition features, such as Table Partitioning or Transparent Data Encryption (TDE), cannot be restored or attached to the SQL Server 2012 Standard Edition without first disabling these edition-specific features. To check this we can use below query.
SELECT [feature_name] FROM [sys].[dm_db_persisted_sku_features]

The [sys].[dm_db_persisted_sku_features] dynamic management view may return rows containing any of the following Enterprise or Developer Edition features:

  • Compression
  • Partitioning
  • Transparent Data Encryption
  • Change Capture

If no edition-specific features have been enabled in the user database, the [sys].[dm_db_persisted_sku_features] dynamic management view does not return any rows.

  1. Once we have list of all these edition specific features then we need to disable all these.
  2. Once we disabled all these features then we can back up the database.
  3. After installation of lower edition, we can restore\attach our database to lower edition and it should work.

Version Downgrades

It is same as edition downgrade, if we want to downgrade Sql server version then we need to first uninstall the higher version and then install the lower version of Sql server. There is no standard tool which can provide this downgrade out of the box. Uninstallation is the only option.

But there is one issue here. You cannot restore\attach those backups which were created in higher versions. The only option to get your database is, you’ll have to create new database in old version Sql and then run all DDL scripts, Data scripts in this newly created database to get everything back.

Following are the steps:

  1. In new version database, create DDL scripts for all objects i.e. tables, SPs, functions etc.
  2. Create all data scripts.
  3. Uninstall current version.
  4. Install older version which is required.
  5. Create new database and run all DDL scripts, DML scripts.

By using above flow we should be able to get our database in lower version.

Below are few points to consider and few points to understand while downgrading.

Database Compatibility Level:

Let’s discuss this with an example. Let’s say you are running your application in Sql server 2008 and now you decided to upgrade you Sql server to version 2012.  Did the upgrade and then you came to know that your application was using some features of Sql server 2008 which are no longer supported in sql server 2012.

Now in this case you need to change the application code so that it should stop using these un supported features of Sql server 2008 and start its alternative features of Sql server 2012. But by the time you make these changes into you application, you want your application to working. You don’t want your application to be in this broken mode.

In this case you will set compatibility level of your new database to Sql server 2008 compatibility level. This compatibility level ensures that it will support all those old features which were there in Sql server 2008. This way your application will not break and you’ll get time to upgrade application code so that it can start using new features of new version.

To see the compatibility level of each database, right click the database in SQL Server Management Studio and select Properties, then click the Options tab. See highlighted field below:

In the image above, I’m running a SQL Server 2008 database, which has compatibility level of 100, on a machine that is running an instance of SQL Server Express 2014 (see the Connection section on the bottom left, my instance name is SQLEXPRESS2014).

Another way to look at the compatibility level of each database on your server is to query the compatibility level column of the sys.databases table:

USE YourDatabaseName;
SELECT compatibility_level
FROM sys.databases WHERE name = 'YourDatabaseName';

The main reason for having compatibility levels is to allow for Backward Compatibility. Each compatibility level has its own set of features. You must program against those features when developing an application that uses the database. If you want to move your database to a newer instance of SQL Server but at the same time have it backwards compatible, you need to make sure the compatibility level stays the same. 

Below is the chart of compatibility levels of different Sql versions.

SQL Server 2012 supports only databases at compatibility levels 90, 100, and 110. Meaning it supports databases going back to SQL Server 2005 only.

Database Version:

Database compatibility levels are not the same as database version numbers. The database version number is an internal number associated with a specific structure of a database’s system tables containing metadata about various objects such as tables, columns, indexes, allocations, and details about the relational and physical structure of the database.

Below is the chart of different versions of Sql server databases.

To identify the version number of a specific SQL Server database, you can query the master.sys.sysdatabases table as follows

SELECT version
FROM master.sys.sysdatabases
WHERE name='AdventureWorks2012'

All databases attached\restored to a newer version of a SQL Server instance, upgrade automatically to the database version that the newer SQL Server instance supports. In the case of SQL Server 2012, all databases created, attached, or restored in a SQL Server 2012 instance convert to database version number 700.