About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.
Full Always On availability groups need SQL Server Enterprise edition. A business application on Standard edition may still need the database to survive a server failure. This article covers the three options Standard edition supports beyond the deprecated Database Mirroring feature: basic availability groups, failover cluster instances and log shipping. Each protects against different failures and each has clear limits.
This article explains what each option does, what it does not do, and how to choose. It does not cover licensing, which has its own rules for standby servers.
Why it matters
High availability is about how long the application is down when something fails, and how much recent data could be lost. The answers differ widely between these three options. Choosing one by name alone can leave a gap that only shows during a real failure.
None of these options replaces backups. Availability groups and log shipping maintain separate database copies; an FCI provides instance redundancy around shared storage. A deleted table can propagate through an availability group or log-shipping restores. Delayed log shipping can leave a recovery opportunity if the error is detected before the affected log is restored.
How it works
Basic availability groups
A basic availability group keeps a second copy of one database on another SQL Server instance. With both replicas in synchronous-commit mode and a connected, healthy synchronized secondary, the primary waits for the secondary to harden transaction log records before acknowledging commit. This is not an unconditional zero-loss promise: if the secondary exceeds the session timeout, it is marked unhealthy/not synchronizing and the primary can continue without that protection. Asynchronous commit does not wait for the secondary, so it can lag. Microsoft's availability modes guide explains these conditions.
The limits are strict. Microsoft lists, among others:
- a limit of two replicas, one primary and one secondary;
- No read access on secondary replica.
- no backups or integrity checks on the secondary;
- Support for one availability database.
The secondary remains inactive unless there's a need to fail over. An instance can hold several basic availability groups, one database each. A basic group also cannot be converted to a full one later; Microsoft says it must be dropped and re-added to a group on Enterprise edition servers.
Failover cluster instances
A failover cluster instance (FCI) protects the whole SQL Server instance rather than one database. It runs on two or more Windows servers in a Windows Server Failover Cluster. Microsoft explains that On the network, an FCI appears as an instance of SQL Server running on a single computer, and that the instance moves to another node if the current one becomes unavailable. Standard edition supports two nodes.
Because the instance moves, everything inside it moves with it: all databases, logins and SQL Server Agent jobs. Applications connect to one name that does not change.
The trade-off is storage. Unlike an availability group, an FCI must use shared storage among all nodes of the FCI for database and log storage. There is one copy of the data. Microsoft notes the shared storage has the potential of being the single point of failure, and that FCI depends on the underlying storage solution to ensure data protection. An FCI protects against a failed server or operating system, not against failed or corrupted storage.
Log shipping
Log shipping copies transaction log backups from a primary database to one or more secondary databases on other instances, and restores them there on a schedule. Three jobs do the work: back up the log on the primary, copy it, and restore it on the secondary.
It does not fail over by itself: A log shipping configuration doesn't automatically fail over from the primary server to the secondary server. Someone must bring a secondary online and point the application at it.
Its distinctive benefit is a deliberate delay. Microsoft notes that a longer delay can be useful, for example, if data is accidentally changed on the primary database. If the mistake is noticed in time, the unchanged data can still be read from the secondary. A secondary in standby mode also allows limited read-only access between restores.
What to choose and why
| Question | Basic availability group | Failover cluster instance | Log shipping |
|---|---|---|---|
| What is protected | One database per group | The whole instance | Each configured database |
| Copies of the data | Two | One, on shared storage | Two or more |
| Failover | Automatic or planned manual only when prerequisites below hold; forced failover can lose data | Automatic node failover subject to cluster health and policy | Manual |
| Readable secondary | No | Not applicable | Limited, in standby mode, between restores |
| Protects against a storage failure | Only with independent storage and a usable replica; check synchronization | Depends on shared-storage protection | Only with independent storage and usable backups; account for restore lag |
| Delay to catch mistakes | No | No | Yes, configurable |
Automatic availability-group failover requires both replicas configured for synchronous commit and AUTOMATIC failover, a healthy synchronized target, and the required cluster/quorum and failover-policy conditions. Planned manual failover without data loss also requires synchronous commit and synchronization. An asynchronous replica supports forced failover with possible data loss, not a normal zero-loss switch. Review the failover prerequisites and validate the application reconnects in an isolated drill.
An application with several databases
A business application may use more than one database. With basic availability groups, each database is in its own group and can fail over separately, so after a failure the application's databases could end up on different servers. Check whether the application can tolerate that, or plan to fail them over together. An FCI moves all databases at once.
Server and logins outside the database
Basic availability groups and log shipping copy database contents only. Logins, SQL Server Agent jobs and linked servers on the primary instance must be created and kept the same on the secondary separately. An FCI does not have this issue, because the instance itself moves.
Combining options
The options can be combined. Microsoft notes an FCI can host an availability-group replica for database-level disaster recovery, but an FCI-hosted replica cannot automatically fail over to another AG replica. FCI node failover and AG replica failover are separate layers; plan the supported manual DR procedure for the latter. Log shipping can also provide a delayed copy.
When Standard is not enough
If the application needs readable secondaries for reporting, more than one secondary, or several databases failing over together within one availability group, those are Enterprise features. Name the need before moving edition.
Risks and limits
- Failover must be tested. A design that has never failed over in a test cannot be relied on. Test on isolated test servers with synthetic data, including the application reconnecting afterwards.
- High availability is not backup. Keep and test backups whatever option you choose.
- Synchronous copies can affect write speed. While the synchronous secondary is connected and synchronized, waiting for its log-hardening acknowledgement adds latency, so the network between the servers matters.
- On hosted VMs, the two servers should not share a single point of failure. Ask the provider whether the two VMs run on different hosts and, for an FCI, how the shared storage is protected.
- Licensing is separate. Standby and secondary servers have their own licensing rules; check Microsoft's current licensing terms.
- No configuration commands are given here. Microsoft's pages cover setup in detail.
Sources
Opened 14 November 2026.
- Microsoft Learn: Basic availability groups for a single database.
- Microsoft Learn: Always On failover cluster instances.
- Microsoft Learn: About log shipping.
- Microsoft Learn: Editions and supported features of SQL Server 2025.
Related service: Cloud hosting.
Related future topics
- Applications reconnecting after a SQL Server failover.
- SQL Server licensing in virtual machines.
- Reporting load on SQL Server.
Learning notes
- Basic availability groups: two replicas, one database per group, no reading from the secondary.
- A failover cluster instance moves the whole instance but keeps one copy of the data on shared storage.
- Log shipping is manual failover, with an optional delay that can help recover from mistakes.
- Logins and jobs are not copied by availability groups or log shipping.
- Test failover, including the application reconnecting, on isolated test servers.
This article was originally published on .