If you can afford SAP you can afford these instances. I think it's a form of signalling to enterprises that the cloud offerings are suitable for them.

HPC people are much technical and less conservative, in general, and can sort themselves out.

I guess because SAP HANA is an in memory database which requires, well, a lot of memory. Other providers use HANA as a reference as well.

I assume that it's one of very few in-memory databases that are a) in actual production use and b) not already trivially distributed/distributable

I.e. just like Azul Systems' system, it's for running bad enterprise applications that you cannot scale with regular means.

AWS do the same: https://aws.amazon.com/ec2/instance-types/x1/

Interestingly, AWS have X1 and X1E-class EC2 offerings, two of which are significantly larger than this new Google offering.

But only Haswell, where GCP offers Skylake

So -80 % memory for 0-5 % more compute throughput?

...but curious to see the performance gain on SAP (or similar) workloads with a new CPU architecture. RAM is the bottleneck typically.

I think their latest instances were 4 socket Broadwell.

Disclosure: I work on Google Cloud.

AWS used it as their reference workload for similarly sized boxes too. SAP HANA is a huge deal in certain sectors. I assume there were plenty of clients they couldn't land without support for it.

SAP HANA is an in-memory database. It's probably one of the more recognizable workloads to require significant amounts of ram.

Maybe because SAP HANA requires vertical scaling. For horizontal scaling, I don't see a point in using such big instances.

On Google, the pricing is by cpu/ram so 1x 96 vcpu instance = 12x 8 vcpu instances in cost. Often easier to just run less of more powerful instances.

Unless you are single process bound, say mysql or postgres instance.

Sure, legacy software is still catching up to multiple cores. Postgres is much better now or you can use SQL Server instead. None of them are native multi-master anyway so scale up is still better than scale out unless you only need reads.

I am not sure it is correct to call Postgres or MySql "legacy software"

To me, legacy software would be something like using Novel PeopleManager 2002 or WordPerfect 7.

Postgres 10.0 is < a week old, and is a perfectly fine path to go for a brand new application. You are fooling yourself if you think you should just throw every new application in MongoDB or Cassandra because they are "web scale".

If you are using "Legacy Software" to mean "software that has existed for a long time", then I guess sure. But there are many pieces of software that are very new, and could benefit from a single instance with a lot of cores.

The most common use of "Legacy Software" is "Old crusty stuff which needs to be replaced", which is NOT at all the case for MySql or Postgres.

It seems you've misunderstood my comments. Perhaps read them again? I'm saying that it's easier to have fewer more powerful servers than many more smaller ones, but even then some software designed for single-node operations still has problems utilizing all the cores (like postgres until recently). I never mentioned mongodb or cassandra.

And that was only for single query to use multiple cores (olap). For oltp multi-core is no problem.

If you don't care about inter node transactions you can use citus for postgresql scaling.

Does have inter-node transactions: https://www.citusdata.com/blog/2017/09/07/citus-7-distribute...

Yes, Citus is good stuff. We use MemSQL though as it's a better fit for our (data warehouse) needs. There's also TimescaleDB, PipelineDB, CockroachDB, and more, lots of interesting options today for distributed "newsql" databases.

You can scale HANA vertically and horizontally. Vertical makes sense for ERP workloads where you want low latency (avoiding communication). The ERP workloads of most companies can fit in RAM easily nowadays. Horizontal scaling is best for data warehousing/analytical workloads, which tend to be more CPU bound due to lots of calculations.

Horizonal scaling costs more in base licensing, not to mention whatever 3rd party stuff you're running in your Hana. Enough to encourage scaling up as far as you can before scaling out.

> You can scale HANA vertically and horizontally

Nah, with scaling, I‘m more referring to approaches of eg Cassandra instead of „add another read replica“.

I wasn't talking about replicas either. HANA can distribute data over many clusters.

https://blogs.saphana.com/2014/12/10/sap-hana-scale-scale-ha...

HANA's roots lie in BWA (SAP BW accelerator), whose main game was distributing large amounts of data across commodity clusters.

I would honestly like to hear of another reference workload for machines of this type. I can't find very many uses other than databases for that much memory.

I think you can store every single uncompressed frame of a bluray movie in memory of an AWS X1... but even then, so what?