Confusion over Microsoft’s HA Terminology
I was talking with a colleague about beefing up redundancy for our SQL Servers backing web apps. VMware’s disk consolidation can unexpectedly take a server offline — not great for customer satisfaction. During the conversation, my colleague kept saying “Always On,” and I immediately assumed he meant Availability Groups. Lesson learned: listen for the full context, not just the buzzword.
He was actually excited about SQL Server 2016 SP1’s licensing changes — specifically Basic Availability Groups in the Standard edition. I clarified that a Basic AG allows only one database per availability group per listener, which wouldn’t work for our scenario. He pushed back, noting that AlwaysOn Failover Cluster Instances with two nodes would work under the Standard license.
That’s when the lightbulb went off. Microsoft’s marketing team conflated two different things under the “AlwaysOn” brand, and it creates real confusion.
What These Technologies Actually Are
| Feature | AlwaysOn AG | AlwaysOn FCI |
|---|---|---|
| Storage | Independent storage per replica | Shared storage required |
| Failover time | Near-instantaneous (seconds) | 30–90 seconds |
| Multiple databases | Yes, per AG | Entire instance fails over |
| Readable secondaries | Yes (Enterprise) | No |
| Standard edition | Basic AG (1 DB per listener) | Yes (2 nodes) |
| Use case | Read scale, DR, HA | Instance-level HA |
AlwaysOn Availability Groups are a newer technology. Databases replicate to secondary replicas using log shipping under the hood. Secondaries can be readable (Enterprise only). When a failover happens, clients reconnect to the listener and land on the new primary. No shared storage required.
AlwaysOn Failover Cluster Instances are the traditional Windows Server Failover Cluster (WSFC) setup with SQL Server — rebranded. Two or more nodes share storage, only one is active at a time, and failover takes 30–90 seconds. It’s the classic SQL cluster, just with Microsoft’s current naming on it.
Which One to Use
For most new deployments where you want high availability and the ability to scale reads, Availability Groups are the right answer. FCIs are still valid when you need instance-level failover and shared SAN storage is already in the picture — or when you’re constrained to Standard edition and need more than one database covered (Basic AG’s one-database-per-listener limit is a real constraint).
If someone says “AlwaysOn” without specifying AG or FCI, ask. The two technologies have different requirements, different failover characteristics, and different licensing implications.
Key Takeaways
- “AlwaysOn” is a marketing umbrella covering two distinct technologies: Availability Groups and Failover Cluster Instances.
- AlwaysOn FCI is traditional SQL clustering (shared storage, 30–90 second failover) with a new name.
- AlwaysOn AGs replicate data independently per database and support near-instantaneous failover with readable secondaries (Enterprise).
- Basic AGs in Standard edition are limited to one database per AG per listener — useful, but constrained.
- When someone says “Always On,” always ask which one they mean.