There has been a lot of talk about in-memory databases in recent months. Initially as a way to speed up analytical applications (although this isn’t entirely new – most databases already offer in-memory OLAP analysis for example). Recently the discussion has broadened with SAP trying to position their in-memory HANA database as a revolutionary replacement for traditional relational databases (RDBMS) – in particular arch enemy Oracle’s database.
Good time for a reality check. Relational databases are used in virtually every commercial application that exists today, so they are not going away anytime soon. A more likely development is that RDBMS will start to adopt some of the technologies of in-memory databases, allowing a large share of existing applications to get most of the benefit from in memory databases without needing to make a bigger investment to move to a database with completely different characteristics and therefore likely incompatibilities. We have seen this before when for example Object, OLAP, or XML native databases were hot. What happened then was that regular RDBMS got some of the same capabilities, such as the ability to index XML content and query it through XQuery. My money is on a similar development this time as well. At the same time in order to get widespread usage in-memory databases will have to adopt a lot of the characteristics of relational databases, such as persistence for backup and recovery purposes, ACID transactions, SQL support and more.
So, should we be happy about in-memory databases? Yes we should. If nothing else they will push vendors to introduce new capabilities (like the ability to load parts or entire databases into memory) in to the databases we all use today. Will the in-memory databases emerging today replace the existing widespread relational databases? No they won’t. Although I would not exclude the possibility of one or two of them over time, and provided they get more similar to relational databases, managing to establish with an at least noticeable market share.