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:
SQL SERVER 2014 IN-MEMORY OLTP HEKATON USEFUL LINKS
Exploring In-memory OLTP Engine (Hekaton) in SQL Server 2014 CTP1
SQL Server 2014 In-Memory OLTP Architecture and Data Storage
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
“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.
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.