Wouldn't the benefit of this local SSD only be to enlarge the size of the buffer pool?

Another idea would be to have the REDO log on local SSD storage for fast writes but the actual data files on remote storage... ?

maxmether you still cannot treat local SSD as persistent storage in this "cloud" scenario where containers are independently moved or stopped. You need all Log writes to be flushed to the network storage device.

Right, it is the write-ahead log that determines what is durable. If we archived all log from the database creation to the current time, the data files could be reconstructed for any past point of time.

My thinking was that by putting the WAL on the SSD we would significantly increase the write throughput (as the log entry of every commit has to be written to disk for the transaction to be durable). Of course if we cannot guarantee that the disk is durable then that of course doesn't work.

High level design.

External buffer pool file.

Fixed size external buffer pool file is created on server start and should be ignored during backup and recovery. The file contains plain buffer pool pages, any information about what external buffer pool page corresponds to what space and page is in-memory. We might also think about external buffer pool file encryption.

Buffer pool integrating

Flushed to external buffer pool file pages are represented with special objects in buffer pool page hash. The objects should have some field that distinguishes it from an in-memory block descriptor near the start. Also either separate LRU list should be used for external buffer pool to evict page from it, or existing LRU should be segmented. When some page is evicted from external buffer pool file because the file is full and the page itself is at the end of LRU list, its description is just removed from page hash, there is no need to change anything in the external buffer pool file.

Storing and loading pages in external buffer pool file

A page is stored in external buffer pool file when it's clean and evicted in page cleaner thread, or when it's dirty and flushed to space. Before reading a page from a space it's checked if external buffer pool file contains it, if yes, the page is read from external buffer pool file, otherwise it's read from data file.

Some update. I worked on this task during the last features development sprint. The general question I tried to solve is how to implement pages flushing to external buffer pool file and pages reading from it. As a result - I implemented the variant where write io requests to external buffer pool file are submitted along with write io requests to data files, and the page is unlocked only when both requests are completed. It passed smoke testing, but there are crashes in some mtr tests, which I plan to fix during the next features development sprint. I pushed my work in ES repository.