É verdade, mas nosso objetivo é um mecanismo de upgrade simples e transparente. Existem vantagens em ambas as abordagens.
Diria que faça o que te deixar mais confortável e não tenha medo de personalizar os templates no discourse_docker conforme suas necessidades. Obviamente, o mais importante é testar primeiro e ter um plano de rollback.
Em nossa plataforma hospedada, pretendemos fazer mais testes e benchmarks antes de ativá-las, e por isso as desativei no discourse_docker também para alinhar a configuração. No entanto, não é estritamente necessário desativá-las (usamos internamente apenas a parte do container web do discourse_docker) e eu não me oporia a ativá-las.
Um possível problema é que o pg_upgrade não funcionará se os diretórios de dados antigo e novo tiverem configurações de checksum diferentes. O processo seria: desligar o servidor PG15, executar o pg_upgrade para convertê-lo para PG18 sem checksums, executar o pg_checksums para habilitar as checksums e, em seguida, iniciar o PG18. Isso não é um problema ao fazer dump e restore (como nesta atualização), mas é algo a se observar.
Note que as checksums de dados estão disponíveis desde o Postgres 9.3, mas até agora estavam desativadas por padrão. O Postgres 19 também incluirá a capacidade de habilitá-las/desabilitá-las online.
Não, não neste momento. A maioria das funcionalidades do Discourse usa o adaptador PostgreSQL do Rails para se comunicar com o banco de dados, mas o backup/restore usa pg_dump e psql no container web. Atualmente, estamos instalando os clientes PG15 e PG18 para permitir backup/restore usando ambas as versões, mas em algum momento no futuro removeremos o PG15.
O fator determinante foi a mudança para o novo provedor de locale integrado. Estamos trabalhando em um upgrade do SO em nossa plataforma hospedada e queremos quebrar o acoplamento com a glibc.