Being the president of the most successful data base company puts a burden on the comments you make with regards to data base systems in general and specifically talking about competitive products. Overstating the capabilities of your own products might be forgiven as being overly excited and optimistic about the potential benefits. But when it comes to competition you should either know exactly what you are talking about, or keep your mouth shut. Bad mouthing competitive products will always come back and haunt you. The more recognized as an expert you are, the more dangerous it becomes. Let's look at the facts:
SAP HANA runs any Oracle based application without any change and mostly significantly faster. This is just due to the fact that with an in-memory database there is no access to the disk any more and more complicated queries are automatically paralleled, utilizing the multi-core architecture of modern servers. If the algorithms are designed well, which is the case for many applications built on Oracle technology, SAP HANA shows dramatic performance improvements.
Fact is: no reprogramming is needed. But, since in a columnar data base all attributes of a table can be used as an index, major changes in algorithms become possible. Let's look at accounts receivable aging, a function every accounting system has to provide. The traditional algorithm runs sequentially through all customers and reads for each customer the open items and classifies the overdue ones by age. Using an in-memory columnar database, we can simply identify all overdue items (reading two columns), sort them by customer and join them with the customer data. The latter algorithm is many orders of magnitudes faster, because we access less memory and can use parallelism.
Fact is: if a database has different properties, different algorithms are optimal and with some reprogramming we can achieve significant further gains.
Fact is: if the columnar store is the primary store for data, the data footprint is 5-10 times less than with a row store as primary store. This is based on the higher compression rates using a columnar store and dictionary compression. To make a columnar store OLTP ready takes some engineering, but is the only solution going forward. To have a row store and a redundant columnar store for the same data is a tactical solution to bridge the time of transition. The 6-11 times larger data footprint is a huge penalty, which basically kills the option to have data mainly in-memory.
Fact is: bringing application logic closer to data, that means to run application logic inside the database, has huge advantages in performance. This always was a trademark of the Oracle database. Unfortunately, when you want to support multiple databases you have to be careful using this architecture, because stored procedures are being coded in different languages in the various databases. Yes, you are right: in order to achieve the best performance, SAP has to adopt stored procedures to a much larger extent. But this has nothing to do with the HANA database, it is an application problem.
Fact is: nobody likes to be replaced by a competitor's solution. A good defense is to build a better product, not to bad mouth the competition with straight lies. The competitor will definitely take advantage of the fact, that lies have short legs (German proverb). Why then do we bother? The image of our industry suffers, when we behave immaturely and show lack of basic knowledge. I hope we can compete on a much higher level.