Enterprise pays off for a requirement, not for a feature list.
"We need Always On, so we need Enterprise." That sentence comes up in many budget talks, and in this generality it is wrong. The failover cluster instance (FCI) and the basic availability group exist in Standard Edition, and they cover a large share of high availability requirements. Enterprise is justified by exactly four requirements, and for three of them there is a Standard path, with trade-offs. This part shows the four requirements, the capacity limits that are often the real driver, and the licensing rules that shape the architecture: what "passive" means, when a secondary needs its own license, and why Software Assurance is part of the HA question. Rules, not prices; your contract is what counts.
In short
- Four requirements justify Enterprise: databases that have to fail over together; local automatic failover plus protection at the second site; a copy that reads reports or takes over backups; operational features such as contained AG, distributed AG, online index maintenance and fast recovery. For the first two, Standard has a path; for the third, none; for the fourth, only manual work.
- Standard can do more than the sentence "Always On needs Enterprise" suggests: an FCI with two nodes, a basic AG with one database and two replicas, log shipping, accelerated database recovery, TDE and, since SQL Server 2025, the Resource Governor.
- The hidden driver is capacity: per instance, up to SQL Server 2022 Standard uses at most 24 cores and 128 GB of buffer pool; from 2025, at most 32 cores and 256 GB. Anyone above that needs Enterprise, no matter how they fail over.
- Passive replicas are a right from Software Assurance or a subscription. Without SA or a subscription, according to Microsoft, even the passive node of a failover cluster needs its own license. With SA: one passive replica for any purpose including high availability, two more for disaster recovery only, one of them in Azure.
- Passive means: the replica delivers no data to users. A readable secondary is therefore not passive and needs its own license. Consistency checks, full and log backups and measuring resource usage are permitted on the passive replica according to the Product Terms.
- A basic AG does not become a full AG. The instance can be upgraded from Standard to Enterprise in Setup, an FCI too; the group then has to be removed and created again.
Four requirements that justify Enterprise
The feature matrix from part 2 lists what the full availability group can do in addition. For the decision, that list helps little, because hardly anyone needs all of it. It is more useful to ask which requirement is behind the wish, and whether Standard meets it another way. There are four.
Several databases have to fail over together
Many applications consist of several databases that belong together: business data, configuration, archive, one database per tenant. If one fails over and the other doesn't, the application is down anyway. The basic AG can't solve this: it contains exactly one database, and several basic AGs on the same instance fail over independently of one another (part 1). The full AG solves it with one group that fails over all databases together.
The Standard path: the FCI. It doesn't fail over databases, it fails over the whole instance, and with it all databases together, including logins, jobs and linked servers (part 1). What it costs: shared storage, a single copy of the data, a failover that is an instance restart with recovery. Anyone who justifies an Enterprise recommendation with "several databases" should first have asked why not an FCI.
Local automatic failover and protection at the second site
The typical requirement of a data center operator: if a server fails, things should continue automatically; if the site fails, a copy should be ready in the second data center. That takes at least three replicas: two synchronous at the first site, one asynchronous at the second. The full AG does exactly that, optionally as a distributed AG across two clusters (part 2). The basic AG has two replicas and can therefore do only one of the two: local automatic failover or site protection.
The Standard path, with trade-offs: FCI for local automatic failover plus log shipping to the second site. Log shipping runs in Standard, has its own data copy on its own storage and, with a delayed restore, even protects against user error, which no AG can do. The price: the role change at the second site is manual work, the data loss equals the interval of the log backups, and logins and jobs have to be maintained there as with any AG. Anyone who can accept a manual site switch has an evidenced Standard architecture with that.
The copy should do work
This is the one requirement without a Standard path. Reading reports on the secondary, running backups on the secondary, offloading integrity checks: only the full AG can do that (part 2). The basic AG secondary allows no read access, no backups and no integrity checks. Passive FCI nodes are stopped; there is nothing to read there. The standby database of log shipping is readable only between the restores, so not for running reports.
Two things belong to this requirement. First, the readable secondary is not free: 14 bytes per changed row on the primary as well, row versions in the secondary's tempdb, possible redo blocking by long readers (part 2). Second, it changes the license calculation: a secondary that delivers reports is no longer passive and needs its own license. More on that below. Anyone who only wants to get the reports off the primary has alternatives: a separate reporting copy through replication or a data extract, time-shifted analyses on a log shipping standby, or the question of whether the reports really disturb the primary.
Operational features that make daily work easier
The fourth requirement is rarely called that, but it hides in many Enterprise wishes: the contained AG (from SQL Server 2022) carries logins and jobs with the group; the distributed AG connects two clusters; online index operations and resumable index builds keep maintenance windows small; fast recovery brings a database online after redo while undo is still running; also online page restore, parallel consistency checks, mirrored backups and hot add memory. According to the edition pages, all of this is Enterprise only, in all four versions from 2017 to 2025.
The Standard path is manual work: maintaining logins with identical SIDs and jobs with a primary check on every replica (part 2), index maintenance in maintenance windows, recovery without fast recovery. At least accelerated database recovery has been in Standard since SQL Server 2019, and it takes away recovery's biggest time sink, the undo phase of long transactions (part 2). Whether the manual work is an argument for Enterprise depends on the operations team: a team with automation can carry it, an administrator doing it on the side probably can't.
The hidden driver: capacity
In many projects, it is not high availability that decides the edition but size. Standard Edition is limited per instance, and the limits are on Microsoft's edition pages:
| Limit per instance | Standard 2017 to 2022 | Standard 2025 | Enterprise |
|---|---|---|---|
| Compute capacity | the lesser of 4 sockets or 24 cores | 4 sockets or 32 cores | operating system maximum |
| Buffer pool | 128 GB | 256 GB | operating system maximum |
| Columnstore segment cache | 32 GB | 32 GB | unlimited |
| Memory-optimized data per database | 32 GB | 32 GB | unlimited |
The limits apply per instance, not per server; several Standard instances can use a larger server. In virtualized environments, the number of logical processors of the VM counts. If the load of a single instance is above these values, the edition question is answered before anyone has talked about failover. And then it is worth thinking about the full AG right away, because it is included in Enterprise.
With the newer versions, Standard has gained a few features that used to be Enterprise arguments: Transparent Data Encryption and accelerated database recovery from SQL Server 2019, the Resource Governor and the higher capacity limits from SQL Server 2025. Data compression, partitioning, backup compression and encrypted backups have been available in Standard throughout since 2017. For availability groups, on the other hand, SQL Server 2025 changes nothing for Standard.
What Standard can do, in one table
| Requirement | Standard path | What it costs | Enterprise path |
|---|---|---|---|
| Catch a node failure automatically | FCI (2 nodes) or basic AG (2 replicas, synchronous) | FCI: shared storage, one data copy; basic AG: instance objects per replica | full AG |
| Fail over databases together | FCI | Instance restart with recovery as the failover | full AG with several databases |
| Survive a storage failure | Basic AG or log shipping (own copy) | Basic AG: one database per group; log shipping: manual switch | full AG |
| Local automatic failover plus second site | FCI plus log shipping | Site switch by hand, data loss at the pace of the log backups | full AG with an asynchronous replica or distributed AG |
| Read reports on the copy | no way | Get a reporting copy another way or read on the primary | readable secondary (own license) |
| Backups on the copy | no way | Backups on the primary | Backups on the secondary, from 2025 also full and differential |
| Carry logins and jobs with the group | no way | Maintenance on every replica | Contained AG (from 2022) |
| Index maintenance without locking windows | no way | Maintenance windows | Online index operations, resumable build |
| Protection against user error | Log shipping with delayed restore, backup | manual switch | likewise only log shipping or backup, no AG |
| More than 24 or 32 cores or 128 or 256 GB per instance | no way (except several instances) | Splitting the load | Enterprise |
The last row before capacity is the most important: against user error, no edition and no replication helps, only a tested backup or a delayed restore. Anyone who buys Enterprise "for security" should have settled that point first.
The licensing rules that shape the architecture
Licensing rules are not a topic PSG likes to put into a technical article, but they shape the architecture, and they are often misreported in HA discussions. So here are the rules from the Microsoft documents, as of Nov 9, 2026: licensing guidance for SQL Server 2025, the Product Terms and the SQL Server 2022 Licensing Guide. They are restatements, not legal advice, and they are not prices. What counts is the contract you have signed with Microsoft or your partner.
Two license models. Enterprise is licensed per core only, Standard per core or by server plus client access licenses (CALs). In the core model, all physical cores on a physical server have to be licensed, at least four per processor; for a virtual machine, the virtual cores, at least four per VM. Licensing per VM requires Software Assurance or a subscription license. Enterprise with SA or a subscription allows an unlimited number of instances in any number of VMs on a host fully licensed by physical cores; the right ends with the SA.
Fail-over rights are an SA benefit. This is the rule that decides architectures: according to Microsoft, passive replicas are a right from Software Assurance or a subscription. Licenses without SA have no high availability and disaster recovery rights, not even for failover clusters: the passive node of an FCI then needs its own license. With SA or a subscription, each licensed primary workload may have up to three passive environments:
- one for any purpose, including high availability, such as the passive FCI node or the synchronous secondary,
- one for disaster recovery only on any server,
- one for disaster recovery only in Azure.
The licenses the passive replica would otherwise need must not exceed those of the primary; a larger standby server is therefore not automatically covered. According to the Product Terms, DR environments have to be operated asynchronously and manually, and a brief test of the DR operation is permitted every 90 days. Whether the passive replica is an AG secondary, an FCI node or a log shipping target is not distinguished by the texts.
What "passive" means. A passive replica delivers no SQL Server data to users or devices and runs no active workloads. According to the Product Terms, consistency checks, log backups, full backups and collecting resource measurement data are permitted. Nothing more. The consequence for the architecture:
- A readable secondary that delivers reports is not passive. Microsoft Learn says explicitly that every instance hosting a readable replica needs a SQL Server license, and the 2022 Licensing Guide requires full licensing for secondaries that do more than pure failover. As a precautionary rule: anyone who sets a secondary to readable should plan it as requiring a license until their own contract says otherwise.
- A secondary that runs only backups and CHECKDB stays within the maintenance list and can be passive. Differential backups, which SQL Server 2025 newly allows on secondaries, are not on the list; anyone who wants to run them there should check the contract.
- The passive FCI node has not started its instance and is the classic case of the passive replica. If two instances run active/active on a cluster, every environment with an active instance needs its own licenses; passive rights apply only to truly passive nodes.
- The basic AG secondary can neither read nor back up; that it counts as a passive replica is not stated explicitly by any licensing source, but follows from the definition. That too belongs in the contract check.
Edition change. A Standard instance can be upgraded to Enterprise in SQL Server Setup ("edition upgrade"), an FCI too: the upgrade on one node is enough, after which you restart the instance or fail over. The service restart is downtime. The opposite way, from Enterprise to Standard, is not an upgrade but an uninstall and a new install, and for failover clusters it is listed as not supported. A basic AG does not survive the change as a group: it has to be removed and created again as a full AG. In licensing terms, the 2022 Licensing Guide calls the change from Standard core to Enterprise core a "step-up", which requires SA on the Standard license; the technical upgrade in Setup does not replace that step.
Where the rules come from. The fail-over section of the Product Terms is word-for-word identical for the programs EA, EAS, SCE, MPSA, MCA, Open Value, Open License, EES and Select Plus. Service provider agreements (SPLA) and pay-as-you-go through Azure Arc have their own terms, which are not checked here. We did not find a Licensing Guide for SQL Server 2025 as a PDF; for 2025, the statements rest on the web guidance and the Product Terms, for the maintenance list and the examples on the SQL Server 2022 guide.
What gets licensed: the same topology, four variants
The same rules applied to an example topology: every server is a VM with 8 virtual cores, so 8 core licenses (the minimum of 4 per VM is met). What is counted is license units, not prices. The column "with SA or subscription" uses the fail-over rights; without SA, every replica needs its own licenses.
| Variant | Requires a license | with SA or subscription | without SA |
|---|---|---|---|
| FCI, 2 nodes, Standard | active node | 8 Standard core licenses (or server+CAL); passive node free | 16 Standard core licenses |
| Basic AG, 2 replicas, Standard | Primary; secondary not readable, no backups | 8 Standard core licenses; secondary as a passive replica (check your contract) | 16 Standard core licenses |
| Full AG, 3 replicas (2 local synchronous, 1 asynchronous at the second site), no secondary readable | Primary; synchronous secondary = passive HA; asynchronous secondary = passive DR | 8 Enterprise core licenses | 24 Enterprise core licenses |
| Full AG, 3 replicas, one secondary delivers reports | Primary and readable secondary; DR replica passive | 16 Enterprise core licenses | 24 Enterprise core licenses |
The table shows why licensing rules shape the architecture: between the third and the fourth row lies nothing but the decision to read reports on a secondary. It doubles the licensed cores. And between "with SA" and "without SA", for every variant, lies the difference of whether the standby is free at all. Both are questions that belong before the architecture design, not after.
Five fallacies
"Always On means Enterprise." Always On is the umbrella term for FCI and availability groups (part 1). The FCI with two nodes and the basic AG are Standard. It becomes Enterprise only through one of the four requirements above.
"We have two nodes, so we need two Enterprise licenses." With SA or a subscription, the passive node is free, in Standard as in Enterprise. Without SA it needs a license, but then in the edition that is running, and that can be Standard.
"The secondary is standby, so let's just pull the monthly reports from it." As soon as it delivers data to users, it is no longer passive. In Standard it doesn't work anyway (basic AG without read access); in Enterprise it costs the license of the second instance.
"We'll take a basic AG and upgrade later." The instance can be upgraded, the group can't. The basic AG has to be removed and created again as a full AG, with new seeding and a maintenance window. Anyone planning that in twelve months should plan the full AG architecture today and clarify the license beforehand.
"Enterprise is bought, so we'll use the secondary too." That is a legitimate decision, but one with a licensing consequence: the secondary becomes subject to licensing. The better order is to first clarify whether reports on the copy are the requirement, and then to license, not the other way round.
Three decision patterns
The line-of-business application with one database. One data center, data loss ruled out, automatic restart in minutes, nobody reads on the copy, the load is well below the Standard limits. Standard is enough. The choice between FCI and basic AG is decided by storage (shared storage available or not) and the team (maintaining instance objects or not). With SA or a subscription, the second node is free. What stays open: failover rehearsed, application reconnects, backup tested.
Two data centers, several databases that belong together. Local automatic failover and site protection, the databases must fail over together. Enterprise with a full AG is the straight path: two synchronous replicas locally, one asynchronous at the second site, all three free as passive with SA as long as no secondary reads. The Standard path is FCI plus log shipping: automatic locally, by hand to the second site, with data loss at the pace of the log backups. Which path fits is decided by the question of whether a manual site switch is acceptable, not by the feature list.
The reports should leave the primary. This is the only requirement that necessarily leads to Enterprise Edition, and it brings the license for the readable secondary with it. A counter-check is worthwhile first: do the reports really disturb the primary, or is an index missing? Is a time-shifted copy enough? Only when the answer is "running reports on current data" is the readable secondary the right architecture, and then with full knowledge of its price in tempdb, redo and license.
Frequently asked questions
Does the basic availability group need Enterprise? No. The basic AG exists only in Standard Edition. In Enterprise, you create a full AG.
Does a readable secondary count as passive? According to Microsoft Learn and the 2022 Licensing Guide, no: an instance with a readable replica needs a license. Plan a secondary set to readable as requiring a license until your contract says otherwise.
May I run backups and CHECKDB on the passive node? Yes, according to the Product Terms, consistency checks, log backups, full backups and collecting measurement data are among the permitted work of a passive replica. Differential backups are not on the list.
Can I upgrade Standard to Enterprise in place? Yes, through the edition upgrade in Setup, for an FCI too, on one node; then a service restart or failover. The way back is a new install. A basic AG has to be created again after the change, and the license change is a separate step.
Do I need Software Assurance for an FCI? Technically no. In licensing terms, without SA or a subscription the passive node needs its own license, because fail-over rights are an SA benefit. In practice, SA is therefore part of almost every HA architecture.
Does SQL Server 2025 change anything about the edition question? Nothing about availability groups for Standard. Standard gets higher capacity limits (32 cores, 256 GB buffer pool) and the Resource Governor; with that, more instances carry their load in Standard. The Web Edition is discontinued, and a free Standard Developer Edition lets you develop and test applications against the Standard feature set, but not run production, DR or backup on it.
What comes next
- Part 4 · Decision guide: eight questions about requirements and constraints, reasoned candidates as the result; no decision from three clicks.
If you're facing the decision
Whether Standard is enough or Enterprise is justified is decided by your requirements, by capacity and by the contract, in that order. In the availability review of our Health Check, we put your goals for data loss and recovery next to what your environment achieves today, and check whether the load fits within the Standard limits. For planning, build and migration, there is our SQL Server High Availability: Design and Build service. We don't sell SQL Server licenses and therefore advise on edition and cores without an interest in license sales; checking your contract stays with you and your licensing partner.
Sources
The technical statements in this part rest on Microsoft documents, checked on Nov 8 and 9, 2026: Editions and Supported Features 2017, 2019, 2022 and 2025; Compute Capacity Limits by Edition; What's New in SQL Server 2025; Basic Availability Groups; Business Continuity and Database Recovery (section Read-Scale); Supported Version and Edition Upgrades 2017 to 2025; In-place Change of a SQL Server Edition; SQL Server 2025 Licensing Guidance; Product Terms "SQL Server" in the program variants EA/EAS/SCE, MPSA, MCA, OV/OVS, OL, EES and S/S+; SQL Server 2022 Licensing Guide (PDF, December 2022). Licensing statements are restatements of these documents without prices and without legal advice; your own contract is what counts. Microsoft also gives the number of synchronous replicas differently in the Licensing Guide than on the edition pages; this part therefore names none.