SQL Server 2022 Licensing Guide for Indian Businesses

SQL Server often sits behind an organisation’s most important systems: ERP, accounting, production, inventory, customer portals, reporting and custom applications. Yet licensing it correctly can be harder than installing it. An Indian business must choose an edition, decide between Server plus CAL and per-core licensing, account for physical and virtual deployment, and understand where Software Assurance or subscription rights affect mobility and recovery. A technically sound server can still be under-licensed, while an oversized licence design can waste budget for years.

This practical guide explains SQL Server 2022 licensing in clear business language. It is based on Microsoft’s current SQL Server 2022 Licensing Guide, Microsoft Product Terms, official edition documentation and lifecycle information. It does not quote prices because channel pricing, agreements, taxes and promotions change. It also does not replace your contract or Product Terms. Use it to prepare a requirement, challenge assumptions and obtain an auditable quotation.

Start with workload facts, not a product SKU

The cheapest-looking line item is not always the lowest-cost compliant design. Begin by recording what the database supports, who or what connects to it, where it runs, how it will grow and how recovery works. A payroll database used by a known internal team has a different licensing profile from a public application serving customers whose number cannot be counted. A lightly used SQL instance in a four-vCPU virtual machine differs from a dense virtualisation host running many production databases.

Identify every component that runs SQL Server software. Microsoft’s per-core guidance applies not only to the Database Engine but also to components such as Reporting Services and Integration Services when deployed on a server. Do not assume that a separate reporting or integration machine is automatically covered by the database server licence. Map production, passive recovery, reporting, test, staging and management instances before requesting a quote.

Discovery checklist

• Application name, owner and business criticality
• SQL Server version, edition and installed components
• Physical server, processor and core details
• Virtual machine count and virtual cores allocated to each VM
• Number of internal users and devices that access the solution
• External users, devices, services, bots and indirect access paths
• Peak usage, database size, performance and availability requirements
• Production, test, development and disaster-recovery topology
• Expected movement between hosts, server farms or cloud providers
• Existing licences, subscriptions, Software Assurance and agreement dates

Understand the main SQL Server 2022 editions

SQL Server 2022 Enterprise is intended for mission-critical workloads that need the broadest scale, performance, high-availability and business-intelligence capabilities. It is available under the per-core model. SQL Server 2022 Standard balances database capability with a lower entry point and can be licensed either per core or through the Server plus Client Access Licence model. The right edition depends on required features and supported scale, not company size alone.

Developer edition provides Enterprise functionality for development and test, but it is not licensed for production use. Express is a free entry-level edition intended for learning and smaller data-driven applications, subject to its technical limits. Evaluation edition provides Enterprise functionality for a limited evaluation period; Microsoft’s documentation states 180 days. Web edition is a specialised option for qualifying web hosters and web value-added providers, not a general low-cost substitute for Standard.

Standard versus Enterprise

Standard can be appropriate for departmental applications, mid-tier databases and many line-of-business systems when its compute, memory, availability and feature limits meet the design. Enterprise becomes relevant when the workload needs capabilities or scale that Standard does not provide, or when a highly virtualised environment makes Enterprise licensing with appropriate Software Assurance attractive. Check the official supported-features table against the exact build because feature availability is more precise than marketing summaries.

Do not select Enterprise merely because a database is important, and do not select Standard merely because the organisation is small. Document the required recovery design, performance envelope, encryption, online operations, analytics and virtualisation. A proof of concept can test technical fit, but production licensing must still be purchased before live use.

The two commercial licensing models

SQL Server 2022 Standard offers Server plus CAL and per-core licensing. Enterprise is licensed per core. These models measure use differently, so a fair comparison must include all required server licences, CALs, core minimums, growth and mobility rights.

Server plus CAL licensing

Under Server plus CAL, assign a SQL Server Standard server licence for each licensed server or virtual operating system environment running the software, then obtain an appropriate SQL Server CAL for every user or device that accesses the server. Microsoft offers User CALs and Device CALs. A User CAL follows one named user across devices; a Device CAL covers one device used by one or more people. The better mix depends on working patterns.

This model can be economical when the population is small, stable and accurately countable. Examples can include an internal application used by a defined finance team or shop-floor terminals shared across shifts. Count all access, however, not only staff who open SQL Server Management Studio. People can access SQL Server through an ERP client, browser, reporting layer, API or another application.

Multiplexing does not reduce CAL requirements. If hundreds of users submit requests through one web server or middleware account, the connection pool does not turn them into one licensed user. The users or devices accessing SQL Server still require licensing under the Server plus CAL model. This makes per-core licensing generally easier to administer for public, partner-facing or high-churn services where the population cannot be reliably counted.

CAL version matters. A CAL must be valid for the server version being accessed under the applicable terms; an older CAL should not be assumed to cover a newer SQL Server. Inventory both server licences and CAL versions during an upgrade. Also remember that Windows Server CALs and SQL Server CALs cover different products; one does not replace the other.

Per-core licensing

Per-core licensing measures compute rather than the number of connecting users or devices. When SQL Server is properly licensed per core, separate SQL Server CALs are not required for access. This is useful for internet applications, large populations, indirect access and environments where user counting would be impractical.

For physical-core licensing, count physical cores in each processor on the licensed server and apply Microsoft’s minimum of four core licences per physical processor. SQL Server core licences are commonly sold in two-core packs, but compliance is measured in required core licences, not simply the number of packs shown on a quotation. Hyper-threading does not change the physical-core count.

For licensing an individual virtual machine, count the virtual cores allocated to that VM, subject to a minimum of four core licences per VM. Beginning with SQL Server 2022, Microsoft states that licensing by individual virtual operating system environment under the per-core model requires subscription licences or licences with active Software Assurance. This is a critical procurement point for businesses planning to license only selected VMs.

How to compare Server plus CAL with per core

Build a three-to-five-year comparison rather than using the first-year purchase alone. For Server plus CAL, include every SQL Server Standard server licence and every User or Device CAL needed across the access population. Model employee growth, shared devices, contractors, service accounts, external users and the cost of tracking assignments. For per core, model physical or virtual cores, minimums, expected VM resizing, host changes and the required subscription or Software Assurance position.

Server plus CAL can fit a controlled internal deployment with few users and several lightly provisioned servers because an eligible CAL can allow its assigned user or device to access licensed SQL servers. Per core can fit a single database that serves many applications or users. There is no universal break-even number; actual agreement pricing and topology determine the result.

Questions for a defensible model choice

• Can every accessing user or device be identified and maintained?
• Will customers, suppliers or the public access the database directly or indirectly?
• Are shared devices more common than multi-device users?
• How many production VMs and cores are required now and after growth?
• Will workloads move frequently between virtualisation hosts?
• Does Enterprise provide a required feature or virtualisation benefit?
• Are active Software Assurance or subscription rights needed for the proposed design?
• Can the organisation retain evidence of licence assignment and reassignment?

Licensing SQL Server in virtual machines

Virtualisation separates visible VMs from physical hardware, but it does not remove licensing obligations. Under Server plus CAL, each VM running SQL Server generally needs the appropriate server licence, while all accessing users or devices need CALs. Multiple SQL Server instances may run within a properly licensed VM under the model, but a second VM is a separate licensing unit.

Under per-core licensing by individual VM, license all virtual cores allocated to that VM, with the four-core minimum. Record the hypervisor configuration and keep screenshots or exported settings showing the allocated vCPUs. If a VM grows from four to eight virtual cores, the licence requirement grows accordingly. Capacity teams should therefore include licensing review in change management.

Enterprise customers may instead license physical cores on a server. Microsoft Product Terms define the number of operating system environments permitted by the licences assigned, and Enterprise with Software Assurance can provide unlimited virtualisation when all physical cores are fully licensed according to the applicable rules. This can be valuable on dense hosts, but it should be calculated from the actual cluster and mobility pattern rather than repeated as a slogan.

Virtualisation mistakes to avoid

• Counting only average CPU use instead of allocated or physical cores
• Ignoring the four-core minimum for an individually licensed VM
• Licensing one VM and assuming every VM on the host is covered
• Moving a VM between hosts without checking licence reassignment and mobility rights
• Buying perpetual licences without Software Assurance while relying on individual-VM rights introduced for SQL Server 2022
• Forgetting SQL components installed on separate utility servers

Clusters, high availability and disaster recovery

Always diagram the live and recovery paths. Availability Groups, failover cluster instances, log shipping, replication and backup restoration can create different running-instance patterns. Microsoft licensing provides specific fail-over rights tied to qualifying licences and Software Assurance or subscription coverage. Conditions distinguish passive fail-over use from active production, readable reporting, backups and other workloads.

Do not describe a server as passive merely because it receives data. Confirm what services run, whether users query it, whether backups are taken from it, whether consistency checks run and whether it serves reports. If the secondary performs production work, it may need its own licensing. The current Product Terms and your agreement determine the rights, so validate the exact topology at quotation and whenever operations change.

Disaster recovery also has operational dependencies. Record recovery time and recovery point objectives, the location of backup copies, recovery infrastructure, DNS and application changes, credentials, and the process for returning to the primary site. Licensing evidence should be part of the recovery runbook; an emergency does not create permanent use rights that were never acquired.

Software Assurance and subscription considerations

Software Assurance is not simply technical support. Depending on the product and agreement, it can provide rights important to a SQL Server design, including new version rights, licence mobility and virtualisation benefits. Subscription licences include rights for a defined term rather than perpetual ownership and may include benefits needed for certain modern deployment patterns.

For SQL Server 2022, the individual virtual OSE option under per-core licensing is explicitly linked by Microsoft to subscription licences or licences with active Software Assurance. Enterprise unlimited virtualisation also depends on appropriate Software Assurance coverage. Workload movement to an authorised outsourcer or across server farms has additional conditions. If mobility is part of the architecture, treat coverage dates and renewal decisions as design inputs.

A lapse can affect future rights even when perpetual licence rights remain. Keep purchase records, agreement numbers, enrolment dates, renewal dates and licence statements. Before discontinuing Software Assurance, model the impact on upgrade, mobility, fail-over and virtualisation assumptions. A lower renewal bill can create an expensive redesign later.

Development, testing and non-production environments

SQL Server Developer edition is a powerful way to build and test because it includes Enterprise functionality but is licensed only for development and test. It must not host production data or serve production workloads. A user acceptance environment may still be non-production, but the purpose, users and data flow should be documented. If customers rely on it, staff run operational reports from it or it becomes a standby for live service, reassess its status.

Use sanitised or masked datasets where possible. Production licensing does not solve privacy or security risk, and Developer edition does not grant permission to expose personal data. Separate credentials, restrict network access and prevent test integrations from sending real invoices, emails or payments.

Express can support small applications within its published technical limits. It is not a licensing shortcut for workloads that exceed those limits, and free does not mean unmanaged. Patch it, back it up, monitor it and plan an upgrade path before growth becomes an emergency.

On-premises SQL Server versus Azure data services

A SQL Server licence purchase should be compared with the right cloud alternatives. SQL Server on Azure Virtual Machines offers infrastructure control with cloud billing and licensing choices. Azure SQL Managed Instance and Azure SQL Database are managed services with different compatibility, administration and commercial models. The best choice depends on application compatibility, latency, operational skills, availability, security, data location and predictable versus variable demand.

Azure Hybrid Benefit may allow eligible SQL Server licences with active Software Assurance or qualifying subscriptions to reduce the licence component of eligible Azure services. Eligibility and deployment rules must be verified for the chosen service. Do not count the same licence benefit twice or assume that moving a VM to any cloud automatically qualifies.

For an Indian business, also evaluate connectivity, support coverage, billing currency and tax treatment with qualified advisers, backup and egress design, and responsibility boundaries. Cloud services can reduce infrastructure work, but the customer still manages identities, data access, application security, retention and cost controls.

Build an auditable SQL Server licence position

Good licensing is repeatable evidence, not a spreadsheet created only during an audit. Maintain a register connecting entitlements to deployments. Store purchase invoices, licence statements, agreement documents, Software Assurance status and renewal records. For each SQL server or VM, record edition, version, host, physical processors, physical cores, virtual cores, installed components, environment purpose and owner.

For CAL licensing, keep a reliable source for user or device assignments and joiner-mover-leaver controls. Reconcile human-resources and device-management records periodically. For per-core licensing, connect infrastructure changes to procurement review. A VM administrator should not be able to double CPU allocation without triggering a licensing check.

Quarterly review checklist

• Discover all running SQL Server instances and compare them with the register.
• Confirm edition and version against entitlements.
• Recount physical and virtual cores after infrastructure changes.
• Review User and Device CAL populations where applicable.
• Identify indirect access through applications, APIs and reporting tools.
• Check passive servers for new active workloads.
• Confirm Software Assurance and subscription expiry dates.
• Review VM movement, outsourced hosting and cloud use.
• Remove or correctly license abandoned production instances.
• Retain dated evidence and management approval for corrections.

Common procurement errors in Indian businesses

The first error is asking for “one SQL licence” without topology. A reseller cannot produce a defensible bill of materials without edition, model, cores, VMs and access population. The second is accepting a quotation that lists packs but does not show the underlying core calculation. The third is comparing a Server plus CAL quote without all CALs against a complete per-core quote.

Other errors include treating Windows Server CALs as SQL Server CALs, using Developer in production, assuming a cold or passive server never needs review, and forgetting that multiplexed users still count under Server plus CAL. Businesses also purchase from channels that cannot provide traceable entitlement, clear terms or an invoice aligned to the customer organisation.

A genuine product key alone is not a complete licence position. Keep evidence showing what was acquired, by whom, under which programme, for which edition and metric, and with what Software Assurance or subscription term. Avoid “lifetime”, recycled, account-shared or unusually cheap offers whose rights cannot be verified.

How to prepare a quotation request

Send a structured requirement rather than only a product name. State whether the deployment is physical or virtual; provide processor, physical-core and vCPU counts; list production and recovery VMs; estimate users and devices; identify external access; and describe movement between hosts or cloud. Note required edition features and the desired agreement term. Ask the supplier to state assumptions, licence metric, quantity calculation, included benefits, renewal position and exclusions.

Request alternatives where uncertainty exists: Standard Server plus CAL, Standard per core, and Enterprise per core when technically relevant. Compare like with like over the expected period. Include implementation, backup, monitoring and support separately from licence entitlement so stakeholders can see what each line buys.

Information your supplier should return

A useful proposal should identify the precise product and edition, the licensing programme or commercial route, the number of server licences, CALs or core licences, and whether core quantities are expressed as individual cores or two-core packs. It should explain every minimum applied and clearly state whether Software Assurance or a subscription is included. The quotation should not silently assume that existing entitlements are eligible; ask for those entitlements to be validated from supporting records.

Ask for a deployment diagram or written mapping between each licence quantity and the servers or VMs it is intended to cover. For Server plus CAL, request the assumed user and device population. For per-core licensing, request the physical-core or virtual-core calculation. For clusters, confirm how fail-over and mobility rights were treated. This makes later reconciliation much easier and prevents a purchasing description from becoming detached from the architecture.

Separate licensing from capacity planning

Licensing optimisation must not create an under-sized platform. Reducing vCPUs purely to lower a licence count can harm response time, batch processing and recovery if the workload genuinely needs the capacity. Conversely, casually allocating spare virtual CPUs can create recurring licensing cost without a business benefit. Use performance evidence, growth forecasts and a controlled capacity test, then license the approved configuration.

Record who can change host processors, VM vCPUs, clustering or recovery roles. Infrastructure changes should trigger checks from database administration, security, procurement and the licence owner. This small governance step closes the common gap between a correct purchase-day calculation and a later environment that has grown beyond it.

A practical decision sequence

1. Inventory every SQL Server workload and component.
2. Classify production, recovery, development and test use.
3. Confirm technical requirements against Microsoft’s current edition matrix.
4. Count users and devices, including indirect and external access.
5. Capture physical cores, processors, VMs and allocated virtual cores.
6. Model Standard Server plus CAL where the population is countable.
7. Model per-core licensing for unlimited access or core-led economics.
8. Validate Software Assurance or subscription dependencies.
9. Review mobility, high availability and disaster-recovery rights.
10. Obtain an itemised quotation and preserve its assumptions.
11. Approve the design jointly through IT, procurement and finance.
12. Reconcile deployments after implementation and at regular intervals.

Conclusion: buy for the architecture you actually operate

SQL Server 2022 licensing becomes manageable when the organisation separates four questions: which edition the workload technically needs, which metric best fits access, which physical or virtual resources must be licensed, and which Software Assurance or subscription benefits the architecture depends on. Accurate discovery prevents both compliance gaps and unnecessary spending.

India Enterprises can help Indian organisations translate application, server, user, virtualisation and recovery requirements into a clear SQL Server bill of materials. Share your topology and business objectives with the India Enterprises Team for an itemised quotation, licensing review and deployment discussion. Final licensing should always be checked against the current Microsoft Product Terms and the agreement through which you purchase.