High availability support is of great importance for systems that are processing large volumes of data.

Starting with SQL Server 2016, SQL Server fully supports the use of memory-optimized objects in conjunction with Always On Availability Groups. Any memory-optimized table will be replicated to the secondary server(s) in the same way that disk-based tables are. For SCHEMA_ONLY tables, the table schema will be replicated to the secondary server(s), but not the data (because the data is never logged for schema only tables). As such, if schema only tables are replicated, a mechanism to re-fill these tables must be included for a failover scenario. If the memory-optimized tables are defined as SCHEMA_AND_DATA, the data will be replicated to the secondary server(s) and will be available to any readable secondary connections that may be reading from the secondary server(s).

Failover Cluster Instances are also fully supported for high availability with the In-Memory OLTP engine. The memory-optimized tables behave in exactly the same way as a standalone instance, meaning that tables defined with the SCHEMA_AND_DATA property will be instantiated at server startup. In other words, they are created and filled using the checkpoint file pairs at startup. Depending on how large these tables are, this initialization can take some time. This is not unique to Failover Cluster Instances, but rather to any SQL Server that uses the In-Memory OLTP engine.

It is now also possible to use replication in conjunction with memory-optimized tables. The initial implementation inside SQL Server 2016 allowed for a transactional or snapshot replication publisher to publish tables to a subscriber, and for the subscriber tables to be created as memory-optimized tables. This means that memory-optimized tables are in fact available on the subscriber-side of replication topology. Using this topology removes the bottleneck of locking and blocking on the subscriber-side and allows the subscriber to keep up with the replication data flow.