SAP used to be database agnostic , that is to say the customer could choose the database that they had pre-invested in ( Oracle, SQLServer, MaxDB, DB2). Can you imagine CFO of SAP looking flow through from SAP per-seat license cost, cutting really big cheques every quarter to competitors Oracle, Microsoft and IBM to license their database products.? Databases products that from a user functional perspective is simply invisible and irrelevant ! In effect sending money to competitors to which they spend improving their competing products. The business minds at SAP must have thought “can we find a way to keep that money inside of SAP? our own database solution?”
Disk or Memory: Oracle, SQLServer and DB2 are in memory DB solutions, in fact almost all customers I have configured recently have database cache hit rates of around 99.9x%, more or less rounding errors given the data needs to be loaded once from disk to database cache. So in effect you can say regular databases are in the age of large memory commodity hardware “in memory”. It is simply BS to say Hana is in memory and the other database are “on disk”.
However HANA does perform, it works really well and does achieve spectacular improvements in speed. Why? Well it is to do with the architecture of SAP, remember each service call to SAP runs inside a “dw” worker process , a single threaded processes interpreting ABAP code, which in turn calls single threaded DB processes that return as single threads the result. The standard architecture of SAP does not support multithread processing and multithreaded (parallel ) DB calls.
HANA performs best when doing analytical calls, the heavy lifting of processing millions of similar facts can be done in parallel and with the data in column store (compressed format for very similar datapoints). In effect SAP pushes the processing down to the database layer to consume a large number of database cores.
Could SAP have created a HANA like performing engine with Oracle (IM), SQL Server (In memory OLTP) or DB2 (BLU) , however I doubt it would have been quite difficult to impossible to write an DB to ABAP abstraction layer that would have allowed SAP to support all in-memory options for all databases….more difficult than SAP building there own specialised DB to do the job: HANA!
The summary is that HANA “in memory” is simply marketing BS, the current crop of SAP databases have in-memory support. The truth is that HANA enables parallelisation with commodity multicore CPUS that the tradition “R/3” single threaded worker and database call architecture did not permit.
SAP has recently released S 4 Hana, which is a rewrite of SAP architecture and code to enable massive parallelisation merging reporting and transactional processing away from the limitations of the old “R/3” paradigm.