SQL Server 2025 Standard Review: Core Licences, CALs and the Memory Cap

Fix it now

Standard is the same engine as Enterprise, fenced in by two capacity ceilings and a shorter availability feature list. In SQL Server 2025 both ceilings moved up: compute is now the lesser of 4 sockets or 32 cores, and the buffer pool cap is 256 GB per instance. The only question worth answering is whether your workload fits inside the fence.

1. Buy it if a single instance serves line-of-business applications and the host sits inside 32 cores and 256 GB of buffer pool.
2. Buy it if you want a choice of licensing model, because Standard is the only paid edition that still offers server plus CAL alongside per core.
3. Buy it rather than stretching Express, whose ceilings in 2025 are 50 GB per database, four cores and 1,410 MB of buffer pool, with no SQL Server Agent.
4. Skip it if you need readable secondary replicas, more than two replicas in an availability group, or index rebuilds that run online during the working day.
5. Skip it if the host has far more cores than 32 or memory well beyond what the buffer pool cap can use, because you would be paying for hardware the engine will decline to touch.
6. Recheck any sizing you did against SQL Server 2022 figures. The core and memory limits both changed with this release.

The buffer pool cap is not the whole memory picture. Standard gets a further 32 GB for the columnstore segment cache per instance and 32 GB of memory-optimized data per database on top.

If the numbers fit, Standard is your edition. The next section is about how to tell whether the ceilings are actually your constraint, which is the mistake this decision usually turns on.

Why it happens

Start with the line-up, because it changed. The SQL Server 2025 editions page lists Enterprise, Standard, Enterprise Developer, Standard Developer, Evaluation and Express. There is no Web edition; Microsoft’s own licensing guidance states that SQL Server Web edition is not available for 2025, although SQL Server 2022 Web may still be available under the Services Provider Licence Agreement. If a quote or a comparison offers you SQL Server 2025 Web, it is describing a product that does not exist.

The two ceilings that define Standard both moved with this release, and anything written against SQL Server 2022 now understates them. Compute is limited to the lesser of 4 sockets or 32 cores, where 2022 and earlier were capped at 24. The buffer pool is capped at 256 GB per instance, where 2016 through 2022 sat at 128 GB. Those are not small revisions: a host you would have sized to 24 cores and 128 GB two years ago can now be used properly on the same edition.

The cap covers the buffer pool rather than everything SQL Server holds in memory. Standard gets a separate 32 GB allowance for the columnstore segment cache per instance and 32 GB of memory-optimized data per database on top of the 256 GB. What is fixed is the main data cache, and that is the part workloads actually notice.

Once the hot working set is bigger than the buffer pool can hold, reads go to disk and the effect is not gradual. Before assuming you need Enterprise, measure it: page life expectancy that collapses under load, sustained physical reads, read latency that tracks the complaints you receive. A workload with a 40 GB working set on a server with 256 GB of headroom does not need a bigger edition. It needs somebody to notice the cap was never the constraint.

On availability, Standard gives you basic availability groups, which means two replicas with one database in each group, no readable secondary and no backups from that secondary. It also supports two-node failover cluster instances, log shipping, backup compression and Transparent Data Encryption. One 2025 change matters to the edition argument: Resource Governor is now available in Standard, which removes one of the reasons organisations used to move up.

The gaps all push in one direction. Reporting served from a readable secondary, more than one secondary, more than two failover cluster nodes, or index maintenance that leaves the table online are Enterprise descriptions, as is licensing every physical core on a host to run unlimited instances. Everything else about the engine, from the full T-SQL surface to row-level security, dynamic data masking and Always Encrypted, is here.

This release is more interesting than the previous couple, and the new features are broadly available across editions rather than reserved for Enterprise. A native vector data type with vector functions and approximate nearest neighbour indexing, so similarity search runs where the data lives. A native JSON type. Regular expression functions in T-SQL. Change event streaming to Azure Event Hubs or Fabric Eventstream. Several of those require the PREVIEW_FEATURES database scoped configuration to be enabled, so check the status of anything you intend to build on before you design around it.

Full reference

Standard against Enterprise, with the 2025 numbers

If you are working from notes written for SQL Server 2022, the two rows to correct are compute, which was the lesser of 4 sockets or 24 cores, and buffer pool memory, which was 128 GB.

Choosing between per core and server plus CAL

Per core licensing is sold in two-core packs, with a minimum of four licences for each physical processor and four for each virtual operating system environment. You count cores rather than sockets, and nobody has to produce a user list, which is the model’s real attraction.

Server plus CAL means one server licence for each operating system environment running an instance, plus a client access licence for every user or device that reaches it. CALs are not tied to one server: Microsoft states that a user or device assigned a single CAL can access more than one licensed SQL Server. They are version-bound in the other direction, since a CAL allows access to the corresponding version of the server software or earlier versions.

The choice is a ratio. Many cores and few users favours server plus CAL. Many users, unknown users, or anyone outside your organisation favours per core, because counting CALs becomes impossible once the public can reach the application. And Microsoft’s multiplexing rule closes the obvious shortcut: hardware or software that reduces the number of users or devices directly accessing the software does not reduce the number of CALs required.

Software Assurance and the failover replica

The right to run a passive failover replica without licensing it is a Software Assurance benefit, and the wording is worth reading carefully because it covers both halves of the licence. For each primary workload you are entitled to one failover operating system environment for any purpose and two more specifically for disaster recovery, and those failover rights require Software Assurance for both the licensed server and the CALs where CALs are used. Stripping Software Assurance out of a quote to make it smaller usually removes the reason the design worked.

Sizing the host around the edition

1. Measure the working set before you size memory. Page life expectancy under load and sustained physical reads tell you whether the buffer pool is your constraint.
2. Count the cores you will actually licence. A processor with fewer, faster cores can cost less to licence and deliver more throughput than a dense part sold on thread count.
3. Check the host against 32 cores. Buying a 64-core server for a Standard instance means paying for silicon the engine will not use.
4. Decide the licensing model before the hardware arrives, because the per core and server plus CAL answers point at different machines.
5. If the workload is non-production, use Standard Developer edition, which is free and mirrors Standard’s limits so you test against the ceilings you will actually run.

When Standard genuinely runs out

• Reporting has to run off a secondary replica. A basic availability group has no readable secondary, and there is no way to configure one.
• You need more than two replicas, or backups taken from a secondary.
• Index maintenance on a large table has to run while people are working. Online and resumable rebuilds are Enterprise.
• You are consolidating many instances onto one large host and want to licence the host rather than each machine.
• You have measured, not assumed, that the working set exceeds 256 GB and the disk reads are what your users are complaining about.

Questions people ask about this