"nada mais lógico do que rodar o DB também em docker"
Discordo desse ponto. Banco não é aplicação e as considerações de engenharia para os critérios de um banco são diferentes de uma aplicação comum, como um serviço de api.
você está adicionando camadas de abstração de um componente crítico, latência de I/O e tornando o processo de backup mais complexo e menos alinhado com as práticas de mercado.
em ambientes de dev/homolog ou um banco de baixa criticidade/volume, tudo certo, mas eu não confiaria na filosofia stateless do docker para rodar um componente stateful crítico para a minha operação.
Em resposta a DB em container degrada o desempenho?
3
1
PostgreSQL em contêiner: é uma boa ideia?
Impacto do Docker: A sobrecarga é mínima, mas sob alta carga pode ser um problema.
Armazenamento (I/O): Sempre use um volume local (-v), senão o desempenho pode cair, especialmente com armazenamento em rede.
Recursos: É essencial configurar limites de CPU/RAM (--memory, --cpus, ulimit), senão o PostgreSQL pode sofrer.
Latência de rede: Se estiver em um cluster (Swarm/K8s), a rede overlay pode atrasar as consultas.
Alta carga: Para milhões de inserções por dia, é melhor instalar o PostgreSQL diretamente no host.
Alternativas: Se quiser escalar facilmente, considere bancos de dados gerenciados (RDS, Cloud SQL) ou Vitess.
Para uso comum, PostgreSQL em contêiner funciona bem. Mas sob carga extrema, o melhor é rodar de forma nativa.