- Hospedar o Postgres por conta própria não é complexo nem arriscado, e é uma abordagem mais barata que os serviços gerenciados, com mais liberdade para ajustar o desempenho
- A maioria dos serviços de banco de dados em nuvem roda uma versão levemente modificada do Postgres open source, e a diferença prática está no nível de automação operacional
- Em casos reais de operação, um Postgres auto-hospedado lida de forma estável com milhares de usuários e dezenas de milhões de consultas, com pouquíssimo tempo de manutenção
- Com o aumento de preço de serviços gerenciados como o AWS RDS, passou a ser possível operar diretamente servidores muito mais potentes pelo mesmo custo
- Para equipes de porte médio em que a gestão de infraestrutura não é tão complexa, a auto-hospedagem se torna uma alternativa realista em custo-benefício e desempenho
A mudança na narrativa centrada na nuvem
- No passado, a maioria das empresas operava seus próprios bancos de dados em servidores próprios, o que resultava em uma arquitetura rápida e com pouca latência de rede
- Entre as décadas de 1980 e 2000, era comum que servidores de aplicação e de banco de dados ficassem no mesmo equipamento físico
- O lançamento do Amazon RDS (2009) foi visto como uma proposta atraente por automatizar backup, patches e monitoramento
- No começo, era possível reduzir a carga operacional pagando um valor parecido com o de um servidor dedicado
- Com a aceleração da adoção da nuvem após 2015, se espalhou a percepção de que gerenciar infraestrutura diretamente era ineficiente
- O modelo em que a AWS cuida da infraestrutura e os desenvolvedores focam na lógica da aplicação se consolidou como padrão
- Em 2025, os preços do RDS subiram bastante, e pelo mesmo custo já é possível alugar servidores dedicados com especificações muito superiores
- Ex.: uma instância db.r6g.xlarge (4 vCPU, 32GB RAM) custa US$ 328 por mês, valor pelo qual é possível alugar um servidor com 32 núcleos e 256GB de RAM
Como os serviços gerenciados são montados na prática
- O AWS RDS é, basicamente, Postgres padrão com sistemas da AWS para monitoramento e backup adicionados por cima
- Inclui backups baseados em snapshots do EBS, gerenciamento de configuração com Chef/Puppet/Ansible, pool de conexões com PgBouncer, monitoramento via CloudWatch e scripts de failover automático
- Isso não é tecnicamente tão complexo; o valor principal está na automação operacional e na praticidade do deploy inicial
- Ao migrar de RDS para auto-hospedagem com um servidor de mesma especificação, o desempenho se manteve igual ou até melhorou
- Parâmetros antes limitados no RDS passaram a poder ser ajustados diretamente, permitindo otimização de performance
A complexidade operacional da auto-hospedagem
- A migração para um servidor da DigitalOcean com 16 vCPU / 32GB RAM / 400GB de disco levou cerca de 4 horas, e depois disso a operação se mostrou estável
- Conjuntos de alta disponibilidade exigem algo como 30 minutos de administração por mês, e serviços com pouco tráfego podem ser totalmente automatizados
- Ciclo regular de manutenção
- Semanal (10 min): validar backups, revisar logs de consultas lentas e verificar espaço em disco
- Mensal (30 min): aplicar atualizações de segurança, revisar a política de retenção de backups e planejar capacidade
- Trimestral (2 h): atualizar dashboards de monitoramento, otimizar configurações e testar recuperação
- A resposta a incidentes passa a ser responsabilidade direta da equipe, mas o RDS também falha, e no fim os desenvolvedores igualmente precisam responder
- Operando por conta própria, é possível controlar quando aplicar atualizações e em que janelas de risco atuar, o que facilita garantir estabilidade
Quando a auto-hospedagem não é adequada
- Para desenvolvedores iniciantes criando protótipos rapidamente, serviços gerenciados são mais simples
- Grandes empresas podem achar mais eficiente ter engenheiros de banco de dados dedicados ou delegar isso à nuvem para reduzir custo de pessoal
- Setores regulados (PCI-DSS, HIPAA etc.) podem exigir o uso de plataformas gerenciadas certificadas
Principais pontos de configuração
- Configuração de memória: é preciso ajustar
shared_buffers, effective_cache_size, work_mem, maintenance_work_mem etc. de acordo com o hardware
- Ex.: definir
shared_buffers em 25% da RAM e effective_cache_size em 75%
- Gerenciamento de conexões: usar
pgbouncer para pool de conexões, com operação eficiente em ambientes Python asyncio
- Exemplo de configuração básica:
max_connections = 200, log_connections = on
- Ajuste de storage: em ambientes com NVMe SSD, definir
random_page_cost = 1.1, effective_io_concurrency = 200 etc.
- Isso melhora a velocidade de leitura aleatória e otimiza o plano de execução das consultas
- Configuração de WAL: ajustar
wal_level = replica, max_wal_size = 2GB, checkpoint_completion_target = 0.9 etc. para equilibrar durabilidade e desempenho
Conclusão
- Não é preciso operar toda a infraestrutura por conta própria, mas o Postgres entra em uma categoria em que a auto-hospedagem é uma escolha razoável
- Se você já gasta mais de US$ 200 por mês com RDS, vale a pena testar a migração de um banco não crítico para um servidor de teste
- No futuro, a infraestrutura pode evoluir para um modelo híbrido entre serviços gerenciados e auto-hospedagem
- O Postgres é visto como um forte candidato à auto-hospedagem pelo ótimo custo-benefício
4 comentários
Como até o armazenamento garante 11 noves, operar é difícil como se estivesse usando a nuvem, então é por isso que se usa a nuvem rsrs
Na prática, operar um cluster de 3 nós provavelmente não vai ser tão fácil assim.
Comentários do Hacker News
Vejo self-hosting como uma questão de responsabilidade
Hospedo eu mesmo alguns produtos SaaS, e sai muito mais barato que AWS, com desempenho muito melhor
Mas, em projetos de clientes, eu os convenço a pagar o custo da AWS. Porque assim dá para transferir a responsabilidade pela disponibilidade do hardware para outro lado
Quando o orçamento é limitado, o custo do RDS pesa. Operar um cluster Galera de 3 nós na Hetzner por alguns dólares é muito mais econômico
Mas serviços gerenciados como Cloudflare ou SQS também falham de vez em quando. No fim, estabilidade perfeita não existe em lugar nenhum
AWS Aurora Serverless
Já o SQL em nuvem tem uma estrutura de custos complexa, e configurar backup uma vez só costuma bastar
Não concordo com a ideia de que self-hosting seja a escolha certa para a maioria
Na verdade, acho que só faz sentido hospedar por conta própria quando o orçamento é muito apertado ou quando a empresa é grande o suficiente para ter engenheiros dedicados
Para empresas pequenas, deixar isso na nuvem é mais realista. As contas fecham com algo como 30 a 120 minutos de administração por mês depois da configuração inicial
PaaS como Heroku ou Render podem ser operados por desenvolvedores comuns, mas custam bem mais caro
No fim, se a recuperação da aplicação não for automatizada, você vai continuar acordando às 3 da manhã do mesmo jeito
Se for uma ferramenta interna, adicionar um Postgres no Docker leva 5 minutos
A definição de ‘banco de dados gerenciado’ está confusa
Para mim, os requisitos básicos são backup automático, otimização de índices, failover entre múltiplos datacenters, recuperação point-in-time, análise de consultas lentas e previsão de armazenamento
Se tudo isso vier incluído na mensalidade, a discussão sobre self-hosting perde o sentido
No fim, você coloca duas pessoas, e como o trabalho fica monótono, elas começam a tentar melhorias desnecessárias e acabam desperdiçando 6 meses
DB gerenciado é caro demais em comparação com VPS
Eu esperava um prêmio pela conveniência, mas na prática custa várias vezes mais. Por isso, não uso fora de projetos grandes
A parte sobre alta disponibilidade (HA) mencionada no texto está fraca. Só explicar configuração de WAL não basta. Replicação custa caro
Não entendo por que o Postgres é tão supervalorizado no HN
Não existe uma forma simples de montar um cluster HA com failover automático como no MongoDB. Queria saber como resolvem isso em produção
Discussão relacionada: lista de e-mails do PostgreSQL
Na prática, todas as conexões caem, o cache é reinicializado e, em upgrades, a interrupção do serviço é inevitável
Só o Oracle RAC é exceção; o PostgreSQL não foi projetado assim. O YugabyteDB é a alternativa mais próxima
A maioria das aplicações tolera algumas horas de downtime. Só grandes empresas conseguem bancar automações complexas
Em Kubernetes, CloudNativePG também é uma boa.
O pg_auto_failover é simples, mas tem limitações
Olhando o Autobase, ele automatiza o trabalho necessário para self-hosting
Há 15 anos eu uso Postgres sempre em self-hosted, e quase nunca tive problemas
A única dor de cabeça foi quando precisei fazer migração de versão do PG para acompanhar upgrades do ORM. Isso foi resolvido com administração de sistemas cuidadosa
Rodei Postgres não gerenciado diretamente na Fly.io e foi um sofrimento
Os nós morriam com frequência, então eu tinha que recuperar manualmente com repmgr, e no fim documentei o processo na wiki interna
O objetivo do cluster era alta disponibilidade, então eu não entendia por que ele não lidava automaticamente com primário zumbi
No fim, migrei para Postgres gerenciado, e é muito confortável quando outra pessoa resolve os incidentes para você
Muitos comentários nesta thread ignoram fatores reais como escala, carga de trabalho, equipe, tempo, estágio do negócio e exigências de escalabilidade
Self-hosting pode ser a escolha certa ou errada; a discussão está simplificada demais
Para os desenvolvedores, provavelmente também é importante se esse tipo de fator é reconhecido quando se faz self-hosting dessas coisas. Mesmo que o custo na nuvem seja maior, se a economia obtida com self-hosting não for reconhecida, no fim das contas parece mais tranquilo simplesmente usar um serviço de nuvem e cobrir isso, reduzindo a área de atuação.