3

Nº de containers de banco 1 por app (cresce sempre) 1 por serviço (fixo)
Memória (overhead duplicado) alto baixo

Isso aqui não se reflete assim não, é uma inverdade.

em alguns benchmarks que eu fiz a diferença de memória entre usar schemas e db isolados no postres é muito pequena. Em partes porque o postgres não tem uma engine que "reaproveita recursos".

A minha situação era multi-tenancy (centenas de schemas na mesma instância) e a economia de memória e processamento simplesmente não ia compesar o risco de manter tudo junto.

Meus DBs usam em média 50MB de RAM.

Compensa o custo de ter uma ferramenta gerenciando isso apenas para economizar alguns poucos MBs?

Carregando publicação patrocinada...
1

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.