SQL Server 2014 In-Memory OLTP (Hekaton) Limitations

One of the biggest new features in SQL Server 2014 is SQL Server In-Memory OLTP, known mostly by its code name of Hekaton (see SQL Server 2014: In-memory OLTP Engine, code-name: Hekaton).  Basically, this puts tables in memory, giving a potentially huge performance boost when accessing these tables, especially with writes (to perform your own performance testing, check out SQL Server 2014 CTP2 In-Memory OLTP Sample).  But be aware that there are currently many features that In-Memory OLTP does not support:

For memory-optimized tables, some of the features not supported are: IDENTIFY or SEQUENCE columns, foreign key constraints, check constraints, MERGE statement, DML triggers, XML/CLR/LOB data types, compression.

Also, with In-Memory OLTP you can natively compile stored procedures (with native_compilation), but the stored procedures can only access in-memory tables.  And there are many features that you cannot use inside a natively compile stored procedure, such as: cursors, CASE statement, CTEs, user-defined functions, UNION statement, PIVOT statement, DISTINCT statement, and many more.

See Transact-SQL Constructs Not Supported by In-Memory OLTP for a comprehensive list of what is not supported.

More info:


Exploring In-memory OLTP Engine (Hekaton) in SQL Server 2014 CTP1

SQL Server 2014 In-Memory OLTP Architecture and Data Storage

Natively Compiled Stored Procedures with SQL Server 2014

Why I don’t (yet) recommend In-Memory OLTP to my customers

About James Serra

James is a big data and data warehousing solution architect at Microsoft. Previously he was an independent consultant working as a Data Warehouse/Business Intelligence architect and developer. He is a prior SQL Server MVP with over 25 years of IT experience.
This entry was posted in SQL Server 2014, SQLServerPedia Syndication. Bookmark the permalink.

3 Responses to SQL Server 2014 In-Memory OLTP (Hekaton) Limitations

  1. Ulises says:

    SEQUENCE objects are supported and they are the recommended workaround for the lack of IDENTITY: http://technet.microsoft.com/en-us/library/dn247640(v=sql.120).aspx

  2. DWalker says:

    “For memory-optimized tables, some of the features not supported are: IDENTIFY or SEQUENCE columns…” I think this is misleading. Sequences are not tied to tables; rather, sequences are bound to a schema. The above comment from Ulises is mostly correct but it also glosses over the fact that sequences are not tied to tables. As far as I can tell, there’s really no such thing as sequence “columns” in Microsoft SQL Server.

    Also, this article seems to be incorrect when it says that “Merge statement” is not supported. Where did that come from? http://blogs.technet.com/b/dataplatforminsider/archive/2014/01/22/merge-operation-in-memory-optimized-tables.aspx talks about how the MERGE statement is handled in memory-optimized tables.

  3. DWalker says:

    Wait, I think I conflated the SQL Merge statement with the “merge phase” of memory management for these tables. The last paragraph of my previous comment can be ignored or removed. Thanks.