Valeu demais pelo comentário, Pilati — e você tá certíssimo. 🙏

Dentro de uma mesma instância, schema/DB isolado custa quase nada de RAM: shared_buffers, WAL e os processos de background são por instância, não por database. Pra multi-tenancy (centenas de schemas no mesmo projeto) consolidar não economiza quase nada e ainda junta o blast radius — não compensa mesmo, concordo 100%.

O número que citei (3.2→1.8GB) é de um caso diferente: colapsar vários containers/instâncias Postgres separados em um só — aí o overhead fixo que se paga N vezes some. Mesmo assim é ganho modesto, não o ponto. Fui infeliz em destacar memória na tabela; já tô corrigindo o post.

No meu caso o objetivo nem é economizar RAM: é homelab com apps diferentes (uns com Postgres, outros Mongo, outros só fila), e o que eu queria era um provisionamento único + backup/restore + credencial isolada por app, sem subir um container de banco por projeto.
Pra um único projeto multi-tenant eu não usaria isso — schema na mesma instância resolve melhor.

(O custo real que eu devia ter destacado: todos os apps ficam presos na mesma major version do banco. Esse sim incomoda às vezes.)

Valeu de novo pela correção.