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.