In this chapter, we covered how the In-Memory OLTP Engine has evolved from the first version released with SQL Server 2014 to the latest version in SQL Server 2016.

Many of the restrictions around data types, constraints, large binary objects, and collations, along with the ability to alter objects without having to drop and recreate them, provide us all with huge improvements for developers. However, we have also seen that there are still limitations and areas where the use of In-Memory OLTP is not the best choice, or must at least be carefully considered before being chosen for a particular implementation.

A vastly more efficient processing engine allows us to consider scenarios where current implementations may benefit from the reduced overhead of the In-Memory OLTP Engine. The ability to seamlessly interact between memory-optimized and disk-based objects makes for a very compelling programming experience. The tooling that Microsoft provides allows us to quickly create an overview of how/where time and resources need investing to take a disk-based implementation and convert it to a memory-optimized solution.

The In-Memory OLTP Engine has made good progress from its initial incarnation in SQL Server 2014 and it is clear that the feature is here to stay. Future versions of SQL Server will no doubt build on the evolution of the engine and provide further integration and support for the remaining data types and programming constructs that are currently unsupported. I for one look forward to seeing this evolution take place and am excited to see developers adopting this fantastic technology in their projects. Now, go forth and see where you can accelerate your SQL Server database projects, by removing those locks and blocks!