Some possible answers
1st off this is MS advertising itself, note the 29X with pointless barchart screenshot. Caveat emptor unless you're stupid.
> When you look up an index it’s just a memory pointer to your data, as opposed to traversing a B-tree.
A btree is a tree structure with an innate ordering. At the leaf level IIRC the db has to scan a page (8K) to find a value. This is true whether it's on disk or in memory (so tables in ram will be so structured, pinned or not). I think they are likely to be using extendible hashing which fits RAM access better and is just pointers to data (note, @skelband et al). Downside is that EH is has no ordering (one reason it's not so commonly used despite having many advantages) which means that certain very common types of queries that work well on btrees don't work well with EH: find the largest widget size smaller than a certain size (say, 30 mm):
select max(size) from widget where size < 30.
I guess this is where the "There are also some code compatibility issues with compiling stored procedures" comes from.
I suspect teradata use EH, from what I've read. I doubt there's anything novel here.
> Compiling stored procedures to native code upped performance further: to 65,000 transactions per second.
Yeah. Define 'transaction' here. Answer: probably what suits MS's setup the best. I also think that compiling stored procs may not be of such great value as after all they are semi-compiled into query plans, and the cost of hitting some complex structures in memory may dominate the one-off cost of parsing some text. Improving the optimiser would often be far more valuable. I don't know what 'compiled' here means, I suspect deceptive marketing bullshit as usual (happy for MS to point out where I'm wrong).
> When you amend a row in Hekaton, you create a new version in memory. When no transactions need to reference the old version, we reclaim the memory
I think this is multiversion concurrency control (MVCC) and may be similar or identical to snapshot isolation which sql server already has. I don't know how that fits in with "Nothing can stop a Hekaton transaction" but that sounds like a challenge to me...
Hah! the very next line says "If the transaction fails to commit, the changes are never written to disk". No contradition here then, obviously transactions are defined as things that only succeed!
And MVCC eats memory - all the sooner for mem to fill up then? (that one @Lee D)
MS would do better fixing the existing problems rather than inventing new boltons which are of specialised use. FYI I don't like MSSQL any more.
All my own opinion, some of this may be wrong. Except the bit about MS should fix problems, and me not liking MSSQL, which are inviolably true.