SQL Server: Core or Server+CAL — licensing calculation for 50–1000 users

The goal: choose a model and avoid overpaying as you grow

The same SQL Server can be “expensive” or quite reasonable just because of the chosen licensing model. At the start, Core and Server+CAL often look comparable, but as users, devices and branches grow the final cost can differ many times.

The issue is usually not that someone “can’t count”, but that the company changes. Today the database is needed by accounting and sales in one office. Six months later two branches connect, some people work remotely, terminal servers appear, and contractors need access for support.

When opening branches three things typically change: more people, more devices (or one person using multiple devices), and access becomes spread across the network. This immediately affects calculations because with Server+CAL it matters whether you license users or devices and who is considered a “connecting” person.

Common questions that come up:

• Count by users or by devices if an employee has a laptop and a phone?
• How to account for shared workstations, shifts and registration desks?
• What about external contractors, auditors and temporary staff?
• How to count access through terminal servers, VPN and from branches?

Where people most often overpay: they buy “with a margin” without a clear growth model. For example, they plan for 200 users "just in case" while realistically there will be 80, but with rapid branch growth in a year. Or the opposite — they buy the minimum CALs and then buy more in bits, hitting inconvenient procurement and approval timelines.

A practical approach: first describe how people and systems will actually connect now and in 6–12 months, and only then choose the model. For organizations in Kazakhstan this is especially important when purchases follow an approved plan and expansion must be justified in advance. Below we’ll go through the calculation steps and give guidelines for 50, 200 and 1000 users.

Core and Server+CAL in plain language

SQL Server has two popular licensing models: Core and Server+CAL. The choice affects not only the price today but how costs will grow when branches, remote workers or new systems are added.

Core is simple: you pay for the server’s compute resources — the number of cores (Microsoft has specifics, but that’s the idea). Who and how many connect to the database is usually not counted separately. This option is convenient when there are many connections and they’re hard to control.

Server+CAL consists of two parts: a license for the SQL Server itself plus CALs to access it. There are two CAL types:

• User CAL — licenses a person, who may connect from multiple devices.
• Device CAL — licenses a device, from which different people may work.

A CAL is basically a “pass” to connect to SQL Server. If you have 200 staff who need database access, that often means up to 200 CALs (or fewer if not everyone needs access, or if counting devices is cheaper).

The main trap is that you can’t compare Core and Server+CAL by eye. Two offers with similar prices today can lead to opposite total costs in a year. With Server+CAL each new branch and every new workstation often adds CALs. With Core, user growth rarely changes licensing until you scale the server.

Example: head office has 50 users and one server. Six months later 5 branches open and another 150 employees start using the system. With Server+CAL you’ll almost certainly buy additional CALs for new users or devices. With Core you think about server capacity and load more than about the number of connections.

Before calculating, understand the access scheme: who connects, from where, from what devices, and how fast new access points will appear.

What baseline data to collect before calculating

Before choosing Core or Server+CAL, gather facts, not guesses. Licensing usually breaks not at the user count but at how people and systems actually connect.

First define what you’re licensing: a single server in the head office, several servers across branches, or multiple SQL Server instances on one machine. Record your 12-month plan: will new branches appear, will there be separate databases for projects, a standby server, a test environment?

Next get the hardware and virtualization picture. For Core, physical cores on each server and how you use VMs are critical. If you plan a cluster or VM migration between hosts, that also affects the licensing scheme.

To avoid missing details, collect at least:

• Servers and instances: how many now, how many will be added in a year, where are production, test and backup located.
• Processors and cores: number of physical cores per server, whether a hypervisor is used and how many VMs run SQL Server.
• Who and how connects: headquarters, branches, remote access (VPN/RDP), terminal servers, contractors.
• Devices: how many devices per person (PC, laptop, tablet), whether there are shared PCs in shifts.
• Integrations and intermediary systems: 1C/CRM/BI, web apps, mobile access, service accounts.

Short example: you have 50 employees, but 10 branches connect to the central database via a terminal server and there’s a web portal for partners. “50 users” stops being a clear figure. List everyone who initiates connections to SQL Server and by which path. That forms the basis for calculation and helps avoid overpaying during growth.

How to calculate Server+CAL: step-by-step

Server+CAL is usually beneficial when you have few SQL Servers and a predictable number of people accessing them. The logic is simple: buy a license for each SQL Server (per server/instance) and separate CALs for users or devices.

Follow these steps to avoid guessing:

Step 1. Describe access to SQL. Who connects from the head office and branches, is there remote access (VPN/RDP), shared workstations (cash desks, registration desks, terminals), integrations (1C, BI, web portal) and who uses them.

Step 2. Count CALs in two variants.

• Per User CAL: count people who need access from any device (laptop, home PC, phone, thin client).
• Per Device CAL: count devices that different people use (shared PCs in shifts).

In practice you often prepare two rough counts and choose the cheaper option that matches actual work patterns.

Step 3. Add server licenses. A SQL Server license is needed for each server where SQL Server is installed. If you plan a test/backup server or a second node for high availability, confirm in advance whether it requires a separate license in your scenario.

Step 4. Allow for growth. At minimum add +20% to the number of users or devices. Separately list new branches and new shared workplaces. A good test: what happens to the budget if another branch opens in a year and two shifts become standard instead of one.

Step 5. Compare with Core using the same inputs. Use the same SQL Server version, access scheme and growth forecast so the comparison is fair.

Small example: a clinic has 60 staff, but mainly 25 doctors use the system and the reception has 6 shared PCs in two shifts. Per User may suit the doctors, while Per Device may be better for reception. You can’t mix CAL types, so choose the one that reflects real access.

If your branch network is growing, document assumptions in writing: number of people, shared devices, server count and the 12-month plan. This simplifies verification with integrators and vendors.

How to calculate Core: step-by-step

Core is convenient where there are many users, access comes from branches, or connections are hard to control. Here the calculation starts with hardware and virtualization, not people.

Record the current and near-term configuration. For each node note sockets, physical cores, and planned changes (add CPU, replace with more core-dense CPUs, add nodes). Without an upgrade plan you can buy “just enough” and then overpay when expanding.

Decide whether SQL Server will run in VMs. If so, know where they will run (on a single host or across hosts) and whether they will migrate between hosts.

A practical calculation scheme:

• Count physical cores on each server or hypervisor host where SQL may run.
• Choose a scenario: license all physical cores on the host (easier for VM mobility) or license only cores dedicated to specific VMs (if your infra constrains resources).
• Count separately per site or cluster: licenses don’t automatically move with a server.

If you plan high availability, include it in the calculation immediately. A passive standby, hot spare or second cluster node often requires another set of cores even if it’s usually idle.

User growth rarely changes the Core license total but does change load. So when branches expand you usually pay for more powerful servers and additional nodes rather than more Core licenses. When upgrading server hardware, check how many cores will be added and how that affects cost.

Quick guidelines for 50, 200 and 1000 users

There’s no single correct answer, but a simple rule helps: Server+CAL is often better when users and access points are few and easy to count. Core often wins when connections are many and hard to control.

50 users. Compare both models honestly. If you have 1–2 servers, office-only access, a small known user set, Server+CAL often looks cheaper. But if some staff use shared terminals, contractors are involved or fast growth is expected, Core is often easier to manage.

200 users. CAL costs start to bite. Branches and remote access matter most: the more entry points and shifts, the higher the chance you’ll miscount and buy CALs in a rush. At this scale companies often move to Core, especially if the database serves multiple systems.

1000 users. Core frequently becomes the natural choice because counting and controlling CALs is hard and connections are numerous. But if architecture is tightly centralized and only a small group of operators actually accesses the database, Server+CAL can still be competitive.

Non-obvious "users" people forget: access via shared accounts on terminals, integrations (ERP, website, mobile app), reporting services, background services, external APIs.

Key factors that change the calculation:

• How many real access points to the database (offices, branches, remote, contractors)?
• Are users named or do they work shifts on shared devices?
• How many systems and integrations access SQL besides humans?
• Will branches increase in the next 12–18 months?
• How quickly can you buy extra licenses without project delays?

How branches and remote access change the calculation

Adding branches changes more than headcount. The number of access points grows: shared PCs at desks, terminals in halls, shift workplaces, temporary contractors. At this stage the chosen model often begins to behave differently than expected.

With Server+CAL you license the right to access. If one employee connects from a laptop, phone and home PC, that’s still one User CAL. But if dozens use one shared computer (for example, a warehouse in two shifts), Device CAL may be cheaper because the device is licensed, not each person.

Remote access amplifies the effect. Once you have RDP farms, VDI and shared terminal stations, it becomes harder to know who counts as a “user” in practice. Hidden connections appear too: integrations, reports, service accounts, external portals.

To avoid overpaying, prepare several scenarios in advance: "+1 branch" (how many people and devices will get access), "+50 users" (new staff or increased shifts), "new integration" (an additional application and how many users it serves), "30% remote" (how many connect regularly).

A useful strategy is to fix access rules in advance (who may connect, from which devices, through which systems) and quarterly reconcile these rules with reality: account lists, devices in branches and the integration inventory. Regular audits often save more money than trying to calculate perfectly once.

Common mistakes that cause overpayment

The most expensive licensing mistake is almost never the license price itself but wrong initial assumptions. Because of them companies buy too much and then buy again when branches appear or work patterns change.

A typical Server+CAL trap: count only full-time employees. In reality contractors, temporary project teams, interns, outsourced accounting or partners often access the database. If they’re not counted, CALs must be bought urgently in parts.

Second trap: confusing users and devices. In shift work (warehouse, call center, clinic, classrooms) Device CALs are often better, but many automatically count by people. Conversely, issuing laptops and phones can make per-device counting suddenly more expensive.

In Core the main overpayment cause usually appears later: the server is upgraded, CPUs or cores are added for new loads, and licenses grow with the hardware. This happens when branch growth increases reporting and load and licensing wasn’t tied to an upgrade plan.

Another confusion: "we have 500 people in the company, so we need 500 licenses." You should count not staff headcount but who actually accesses SQL (directly or via applications). Sometimes only tens of staff use the database.

Quick self-check before buying

• Who besides staff will connect: contractors, auditors, temporary roles?
• How many devices and how many people actually use access; are there shifts?
• Are CPU/core upgrades planned in the next 12–18 months?
• Which systems and applications access SQL; are there service accounts?
• What is the architecture: single server, multiple VMs, cluster, test environments?

If the architecture isn’t fixed (for example, SQL will move to virtualization or a cluster), estimating by eye is especially risky.

Short checklist before buying licenses

Before purchase record inputs in writing (or a spreadsheet). A mistake here usually costs more than the difference between models.

First collect a full picture of SQL servers: current specs and planned changes for 12–24 months. If licensing is Core-based, CPU and core plans directly change the final amount.

Then break access into clear groups: head office, branches, remote workers, contractors, and service accounts (integrations, connectors, apps, backups). Important: count not who is on the company roster but who actually connects to SQL and from which devices.

Mark shared workplaces separately (shift posts in call centers, reception, warehouse). In such places Server+CAL is often counted by device, which changes arithmetic.

Briefly record the growth plan: when branches open, how many people are added per quarter, and any seasonality (e.g., university admissions or retail peaks). This shows when Server+CAL will start to catch up with Core in cost.

Finally choose a review rule so the calculation doesn’t become outdated in 3 months: who owns the user and device lists, how often figures are updated (e.g., quarterly), how contractors and temporary access are handled, what counts as "connecting to SQL" in your company (direct access, via app, via terminal), and which events require recalculation (new branch, service launch, server upgrade).

Example: branch network growing from 50 to 200 users

Imagine a company with a head office and 6 branches. There are cash desks and operators working shifts on shared PCs. Some employees connect remotely (laptops, home PCs) and access the database through corporate accounts.

Option 1: Server+CAL (and where mistakes are easy)

It may seem logical to count by devices now: 50 employees but 30–35 shared workstations in branches plus several PCs in the office. Device CALs look cheaper.

The problem arises when growth reaches 200 users: remote access and mobile devices increase the number of "devices", and shift work no longer protects you. A frequent mistake is counting only stationary PCs and forgetting laptops, personal devices, terminal farms, new branches and temporary staff.

Another risk is hidden access: people log into an app that queries SQL on their behalf. Licensing rules still count that access.

Option 2: Core (and the upgrade risk)

With Core you license server cores and don’t need CALs. For example, SQL on a server with 16 physical cores requires coverage for all 16.

The risk is different: if next year you replace CPUs or add a second CPU increasing cores to 24–32, you’ll need additional core licenses and any savings versus Server+CAL may disappear.

How to decide without guessing

Compare the 2-year estimate, not only "today". Make a table of assumptions and calculate both scenarios.

Add to the budget for approval: chosen model, user/device growth, server plan (so cores don’t suddenly balloon) and a margin for new branches.

Next steps: lock the choice and prepare for growth

To keep the decision stable, write a short 1–2 page document with your assumptions, planned timeframe and the owner of access accounting. This prevents surprises when a new branch opens or remote work spikes.

Make parallel calculations for Core and Server+CAL for 12 and 24 months. Use identical assumptions: same SQL Server version, same access rules, same growth forecast of users and devices.

Fix the architecture that determines cost. One powerful server leads to one licensing scenario; multiple nodes or virtualization lead to another. Note whether you plan a standby server, a test environment and how recovery will work.

Often the biggest savings come from simple management steps: assign an owner for access accounting, define rules (including contractors and service accounts), link growth forecasts to real events and agree on a server upgrade plan (because adding CPUs/cores changes Core economics).

If you plan hardware upgrades, calculate licenses together with server and workstation configurations. In practice, infrastructure changes often shift the boundary where Core becomes cheaper than Server+CAL. If you need help designing such a scheme for branch growth, this is usually done as part of system integration — for example, at GSE.kz (gse.kz) you can simultaneously plan server configuration, access points and support so the chosen licensing model rests on real architecture, not assumptions.