>>No, Table in memory is faster (2x-3x) for writing than standard table, because use another engine.
>
>Is there any side effect? Because, if this is so fast, I wonder why Microsoft simply did not put that in the core instead of an option.

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.