At one point Kurian rattled off a litany of claims about Hana limitations that would make a would-be customer's head spin. Let's lay a few of those to rest.

* Hana does support SQL and MDX.

* Hana does support parallel query execution. In fact, it supports massively parallel query execution.

* Hana does not support a bunch of stuff related to ROLAP and MOLAP--like indexes, aggregates, and materialized views--because it does away with those artifacts entirely. It makes calculations instantly on the fly--using the latest data and all available detail. SAP's analogy: Hana doesn't need a MOLAP hay loft or a materialized view whip because it's not a horse and buggy; it's an automobile.

* Hana does support unstructured data analysis. In fact, the database's origins were in columnar text processing, and SAP BusinessObjects has since added text-analysis capabilities that can be used in conjunction with Hana.

[ Want more on in-memory analysis needs? Read SAP And Oracle: Get Real About In-Memory Analysis. ]

One key point by Kurian that IT leaders need to consider: "If you have a data warehouse or mart in which only a small amount of the data is actually hot, why would you put it all in an in-memory-based system?"

I've asked SAP that same question more than once and have been told that:

A. DRAM is getting so cheap it will inevitably replace disk, and

B. that if the archives are truly large, Hana will work with warehouse-oriented products such as Sybase IQ.

However, if you still need a separate warehouse, it kind of defeats the argument that you can do away with extra database licenses and layers of unnecessary infrastructure. Until disk-based memory is truly obsolete, customers will have to consider what's hot and what's not and ask tough questions about what's required for the in-memory performance they're after.

On the subject of Hana's cost, Oracle's apples-to-apples comparisons to Exalytics aren't appropriate because the data footprints and database license and hardware requirements would be vastly different even for the same customer. With one copy of data with Hana instead of two or three with Oracle--plus the elimination of redundant aggregates, indexes and materialized views--Hana users could expect to have a much smaller data footprint. The average reduction won't be known until the market sees more BW-on-Hana deployments, which will take some time. As for applications on Hana, well, we'll have to wait until that becomes a reality.

Getting To The Bottom Line

Pricing Exalytics in a small data-mart scenario at around 500 gigabytes, Kurian said the hardware would be $135,000 and the TimesTen database another $690,000 for a total of $825,000. (He did not mention Oracle BI Foundation software, which is also required.)

By comparison, Kurian claimed SAP's cost would be $362,000 for hardware and $3.7 million for software. SAP's Steve Lucas says Hana's cost in this scenario, including hardware and software, would be $500,000, but by my calculation, using BW-on-Hana list prices (of $79,000 per 64-gigabyte unit, as reported here ) and a 50% database overhead allowance (which SAP calls for), the software cost alone would be north of $1.2 million. SAP must be counting discounts and incentives it's throwing in to spur sales.

The bottom line is that Oracle's claim that Hana costs 5-to-50-times more than Exalytics is exaggerated--in large part because it's based on same-size deployments, when Hana will allow smaller deployments. But it's also hard to believe SAP's sweeping statements about the affordability of DRAM-based systems and Hana overall.

"The reason why new applications have been emphasized is that Hana is expensive," says Gartner's Feinberg. "So you need an application that's going to give you strong business value."

That customers can now run BW and Planning and Consolidation on Hana brings more value to the equation. But customers won't see the full potential of Hana until it's running the warehouse, the core transactional applications, and a breakthrough, business-value-driving new application.