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 2017.

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, signal the need for huge improvements for developers. We have also learned 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.

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 and 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. The evolution from SQL Server 2014 to 2016 and finally to 2017 shows that the engine continues to be improved, adding further integration and support for the remaining data types and programming constructs 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 and remove those locks and blocks!