Why PostgreSQL's random_page_cost default never matched real storage
Some more thoughts on random_page_cost

In this follow-up to his earlier analysis, Tomas Vondra revisits PostgreSQL's random_page_cost parameter. He presents benchmark results from rotational SATA drives showing an estimated cost of ~125, far above the 4.0 default, and argues that the default never represented raw random I/O cost. He explains that random_page_cost compensates for gaps in the planner's cost model, which ignores memory usage and caching effects. Lower values encourage more localized plans that keep the active set in memory, making tuning system-specific and dependent on monitoring rather than storage profiling.
I now see random_page_cost as a proxy for all these effects.