DB scenarios with heavy load and a lot of idle time

When it comes to distributing the load between database and application server, web server, and internal report servers, often various approaches were discussed some purely by ideology driven.
Some realistic real world examples:

1. Nearly all load should be in the memory of application and web servers
   with many dynamic objects, and almost NO load should hammer the database.
2. Only Entity Framework Core
3. No EFCore at all, because only Stroed Procedures can be administrated more secure. and last but not least can guarantee atomicity, fetch of reduced result sets, that you really need and NOT huge views from the entire database.
4. Optimized stored procedures with execution plan sniffing will solve heavy load problem.
5. Entity Framework Core with stored procedures is also must have for 4.
6. EFCore SProcs is only a nuget package of unknown origin, I only trust Microsoft.
7. Can you search git please: https://github.com/verdie-g/StoredProcedureEFCore
   Ah, origin seems to be very clear for me.
8. This package is archived since 22.10. MS can do it directly:
   https://stackoverflow.com/questions/28599404/how-to-run-stored-procedures-in-entity-framework-core
9. Reducing wait time of (dead-)locks in case of only read access
   by uncommittable reads, that totally avoid table and row locks
10. Fast memcaches to partially buffer the database
    only write-through  works
    must implement lazy loading strategies
    clever buffering, instead fully write through 
11. ...

To understand the situation better, I draw 2 different scenarios and you will immediately see why the database in Scenario 1 is always under heavy load and further load is critical,

while the database in Scenario 2 is almost always idle.

What I mean you really must take care to avoid any further huge db load in scenaria 1,
but not in scenario 2.

If you want for your external business application in a scenario 2 (most cloud databases are optimized on relational data and databases are stored often on a seperated optimized disk in raw format, so this is already a performance advantage to c:\*.mdf;*,ldf, where all windows services and system programs permantly have high IO, see https://youtu.be/ybNXf4t4zT4)
then contact cloud pilots to see your database in azured mediterranean sea or tech racer to get more amazon power, instead under heavy violent high-pressure thunderstorms.

If you like more european clouds, I found https://clouding.io/ in Barcelona and transfered Paris amazon locartion to it. Spanish cloud in Madrid and US in west virginia is still amazon.

You know why?

Because a lot of companies with 1-2 business application mostley hammer their own database from inside and produce them self a lot of traffic and database load, because they want to keep their business important. 
Moving an application and database to the cloud is truly truthfulness,
because it allows you to better understand attitudes of customers, internal users and bots, who visit your application. A realisitc view is better to plan for the future and rethink strategies of re-.growing your business.
If you want to grow, you can dynamically and quickly scale up CPUs, memory, and disk space in the cloud.