Ultimately I think the HANA database is an overhyped in-memory database. The reason they make money with HANA is that they are successfully replacing Oracle Databases for their SAP on-premise customers.

SAP HANA is an in memory database. That’s all it is. It’s similar to Qlikview if you’ve used that. It’s licensed per socket, so scaling up is better than scaling out.

SAP will also host HANA for you, for a fee.

See. The thing is: SAP is a company for HR departments. The kinds of departments that aren’t technical, do not have technical staff to develop thing for them. (It’s an example) but your HR department talks to SAP, they deliver some service, sometimes something that the barely tech-literate members of HR is able to build on and then suddenly your sysadmins have to support those things in perpetuity.

Well. They market themselves as this anyway. And I have experience of our HR department buying all kinds of stuff from SAP and their child companies. (Concur, for example).

So I understand your incredulous-ness. This company is not made for us. And most of their tech isn’t either.

And finance. And operations. And compliance, and ...

> The kinds of departments that aren’t technical

Which, in most businesses, are almost all of them. That's why they are so entrenched and so profitable, despite selling an utterly unfashionable and over-complicated stack.

I suspect they also want information back from you, and most likely in a SAP compatible version.

This was all told to me at our IT quarterly meeting, with our new SAP deployments, as IT does not actually input the data, just run the servers.

Funny how we run the stuff, but sometimes dont even know how its used.

ERP applications which use HANA typically do have significant random accesses in their workload. It is due to this reason that it was initially marketed as an in-memory database. The random access performance of RAM was necessary for high performance. If HANA was just being used in in-memory mode, the speed increase is probably not that impressive. But, if there is non-volatile storage involved, then yes the speed increase would be impressive.

You can get good performance out of it, no medals there as any IMDB would give you that.

My pain points were:

- it is sold as the virtualisation layer to rule them all, until you find crazy breakages. SAP's SQL dialect is case sensitive. That'll frustrate a lot of downstream databases that you deal with, or the users thereof.

- virtual warehouse. I'm not a Kimball expert, but our resident experts came to the same conclusion as I did, that you can't really build useful VIRTUAL data marts directly from disparate downstream data sources without persisting that somewhere. That then defeats the purpose, in my quasi-professional opinion.

- I spent over a month looking at the SDA/SDI to "Big Data" parts. Very immature, found interesting instances where push-down of predicates were inconsistent and poor. It's one thing to say you've got Apache Spark integration, but it's another thing when your system can't figure out that data comes from the same system, and this you could do some expensive computations downstream instead of saturating the network pulling a lot of data. I did my work early this year, so I would expect improvement here. The problem though was that many of us started feeling like SAP are releasing a product that should spend more time in development before coming to us. I'm entitled to say so because they charge an arm and a leg.

- data modelling/development. SQL is Turing complete, but some things are still hard to do in it. Instead of giving us more capabilities when modelling our data, they're getting "distracted" by wanting to tuck marketing boxes like R support, NodeJS support, etc. I didn't spend enough time on those to feel comfortable with producing a fair opinion, so I'll reserve one.

- SDLC, security. SAP has solid products there, and I learnt quite a lot around security integration. There were some quirks, but those were largely because of our requirements, not SAP. I enjoyed working on data access and security patterns.

- IDE. They initially used a modified NetBeans, which was also available as a plugin. I'm not a NB person, but this was solid. They decided to move to a web-based IDE. I don't know why, but they deprecated certain things while their web thingy was not even feature complete. It was a growing mess when you'd find that you can only do something in X but not Y.

To recap, a high cost for performance that you could get from a competitor, or even a well baby-sat Apache Ignite cluster (for the features they support, at least they aren't lying in their marketing). I think of it as a lame caching layer, that's useful if you're already invested in the SAP ecosystem, think of SAP CRMs or even their warehousing as a stretch.

So, no; it's not revolutionary in my view. The "specialised hardware" is marketing bait, our IT (I too was) were convinced that one could build themselves the same hardware as was speced. When I first heard of the special hardware thing, I thought of a custom Intel with features that only SAP would have, DDR4 RAM at crazy clock speed, etc. Only to find that it's a sly way of controlling how much they charge you. "Want to add moar RAMs? Pay us so you don't vid warranty, and we'll charge you more of course for the extra RAM".

To conclude my rant, I hope you've found my view useful. My conclusion when I rolled off from my SAP HANA (notice how little I've used this acronym, I despise it) project feeling like it was making everyone in the room bad. People were forsaking their Oracle DBs and Hadoop clusters to make design compromises for an over-marketed database thingy.

EMC did something similar with avamar... you’d buy spray painted SuperMicro boxes runnding RHEL and pay for software as well. Come node end of life, you have to buy the software and hardware again, even after paying the 20-25% maintenance.