To be fair, utilizing 192 cores for a single process or operation is often exceedingly difficult. Scheduling and coordination and resource sharing are all really hard with thread counts that high, so you're probably best operating in terms of smaller clusters of 4-16 threads instead. Lots of algorithms stop scaling well around the 8-32 range.
I think a simple way to think about this is with more cores comes more scheduling complexity. That's without even considering how well you can parallelize your actual tasks.
If instead we break 128 cores into 4 core systems, scheduling becomes a much less complex.
Oracle enterprise database actually has a retail license cost of $47,500 per cpu core. On x86, there is a two-for-one license discount.
In my setup, I have an nfs automount set up from a 12-core machine to my 8-core database. The rman backup and the scp happen locally, but yes, the lzip runs on the compute server.
I've run plenty of microservices with 256 or 512 GB of RAM, and they were handling large loads. So long as each request is short lived, and using a runtime with low per request overhead (e.g. Node), memory is not really a problem for many types of workloads.
