>It's an option because Hekaton tables are basic row stores that synchronized with filestream objects, depending on the persistence model you use. There's far less overhead, but also some loss of functionality in stored procs (as far as what language statements you can use), and also some loss of functionality in triggers
>
>SQL 2014 enterprise has a profiler (it's called the AMR tool) that you can use to see which tables would be good candidates for Hekaton.
>
>Hekaton is one of those features where you can say...."not everybody can use it....and even if you can use it, whether or not you'll get performance increases depends on different factors....but when you do get performance gains, they are huge"
>
>Because Hekaton is basically a 1.0 feature in sql 2014, it certainly isn't perfect. I have one client who makes good use of it, and 2 where the value is limited. In SQL 2016 Microsoft is greatly enhancing it - as a result, more people will be able to use it. Even if you can't use it today, it's a good idea to keep track of what MS is doing- because in-memory optimized tables/columnstore indexes is definitely a big direction Microsoft is going with SQL Server.

We will looking at this with SQL Server 2016. But, this certainly sounds interesting.