Krishnan Subramanian and I were chatting over Skype yesterday.  Krishnan is a well-known analyst and blogger. He asked a question about a post I wrote this week that looked at ten startups in the flash memory storage market. He wanted to know this:

We saw the proliferation of in-memory databases in the last few years. Now with SSDs going down in cost and more and more SSD storage coming into play, will in-memory databases in the enterprise side stay relevant or will we be seeing a shift towards SSD based ones?

In the tweet stream, the always colorful Dennis Howlett replied to my reference to Krishnan, wanting to know if I understood what Krishnan was communicating in our conversation or did I just pretend?

Well, Dennis, I told Krishnan that I would have to research the matter and you may be the far more intelligent one in this circle. You are a well-known pundit who knows SAP better than any analyst/blogger that I know. And as we know, SAP is heavily invested in the development of in-memory databases with SAP HANA. But how does this strategy fit with the growing popularity of SSDs?

I asked Ben Stopford for some perspective. Stopford wrote a great post this week on distributed storage, phase change memory and the rebirth of in-memory databases.

I posed the question on his blog. He had this to say:

In short you are right but I’ll address both your questions in one:

Memory is still a lot faster than SSD, even Fusion IO. Several orders of magnitude (and whilst theoretical throughputs are similar they are not comparable in practical applications). Connecting a traditional DB to SSD storage gives you little (as the refs above prove). They are simply not architected to take advantage of the technology.

In memory databases should be able to make a comeback simply due to the large address-spaces we are seeing today. SSD provides the mechanism for getting around the problems that have hindered in-memory solutions to date.

For better solutions a couple of likely options:
– A new architecture could leverage RAM primarily with SSD providing the durability and some extensibility. This changes the architecture to a single address space one which is far simpler and faster. The key point is all data is in RAM.
– A different new architecture could leverage SSD technology directly without getting caught up with problems of big user spaces etc that plague traditional disk based architectures, instead treating SSD as an extended address space. The key point here is that the data lives on SSD.

Dennis Moore wrote a detailed post in June about SAP HANA. A question surfaced in the comments, asking how SAP HANA will compete as SSDs get faster.

Moore makes the point that relational databases were designed for a time when memory was fast but ultra-expensive, processors were much slower than today. They also had other limitations, such as much smaller caches. There was a lot of work to do in optimizing data brought into limited memory.

He maintains that HANA’s in-memory compute engine was not designed with these arcane assumptions. HANA, in that respect, should always outperform a database that would be based upon old practices.

Moore:

All databases (including HANA) should benefit from such faster memory, but – assuming you have enough memory to hold your entire database in memory – HANA should outperform traditional databases no matter how fast such permanent storage can get.

This is because in-memory databases, like HANA, do not have the overhead burdening Oracle, DB2, and other traditional databases. This overhead is related to disk management, cache management, and optimization for disk retrieval.

So, Dennis, what do you think?