Further to the previously mentioned size limitation removal, there have been a number of improvements of the In-Memory OLTP engine that may not be immediately apparent, but can still drastically improve performance and scalability.

First up is a range of improvements to the storage subsystem; not only was the checkpoint file pair limit removed, but there was also the introduction of multi-threaded checkpointing. In SQL Server 2014, the offline checkpoint process was a single-threaded system. This thread would scan the transaction log for changes to memory-optimized tables and write those changes to the checkpoint file pairs. This meant that a potentially multi-core system would have a busy core for the checkpointing process. With SQL Server 2016, this checkpointing system was redesigned to run on multiple threads, therefore increasing throughput to the checkpoint file pairs and thus increasing overall performance and the scalability of the In-Memory OLTP engine.

Similar improvements have been made to the recovery process. When the server is performing crash recovery, or bringing a database online after a server was taken offline, the log apply operations are now also processed using multiple threads.

The theme of multi-threading, or parallel processing, has also been continued in the query processing portion of the In-Memory OLTP engine. Here, we can expect performance improvements for a range of queries, both interpreted and natively compiled.

The query processing engine is now able to process the MERGE statement using multiple threads (as long as your server and database MAXDOP settings allow for this). This allows the query optimizer to use parallelism where it deems parallel processing to be more efficient than serial processing.

Equally, in SQL Server 2014, hash indexes could only be scanned using a single thread or serial scan rather than a parallel scan. SQL Server 2016 implemented a parallel scan method to provide a significant performance gain when scanning a hash index. This helps to mitigate the inherent performance pain that is experienced when performing an index scan over a hash index.