PostgreSQL auto-hospedado em uma VPS: fuja dos preços de bancos de dados gerenciados

Computação. Armazenamento. Retenção de backups.

A exportação de snapshot que você esqueceu. A taxa de tráfego de saída do ambiente de staging que rodou um ‘pg_dump’ na terça passada.

Ninguém abre a fatura do banco de dados gerenciado esperando que ela seja barata.

Mas, poxa.

A distância entre o Postgres por US$ 25 por mês e o valor que aparece no cartão ficou grande. Hoje, uma VPS de 4 GB pelo preço de um único complemento do Supabase roda todo o seu banco de dados, com folga para o sistema operacional manter em cache as páginas mais acessadas.

Auto-hospedar um banco de dados Postgres em produção não é mais o pesadelo operacional que já foi. O repositório do PostgreSQL Global Development Group (PGDG) é sólido. Instalações modernas do PostgreSQL (v14+) usam por padrão a criptografia de senha SCRAM-SHA-256, e o MD5 legado foi oficialmente descontinuado a partir da v18. Hoje, os motivos para continuar no RDS, Supabase ou Neon são operacionais, não técnicos.

Vamos falar de faturas reais, de sobrecarga operacional real e de como a hospedagem moderna de Postgres realmente funciona.

Quanto custa, de fato, auto-hospedar o PostgreSQL em uma VPS?

Um PostgreSQL auto-hospedado em uma VPS de 4 GB costuma custar uma fração do preço equivalente do RDS, Supabase Pro ou Neon Scale, depois que armazenamento, backups e tráfego de saída entram na fatura do serviço gerenciado.

O PostgreSQL é o banco de dados usado por 55,6% dos desenvolvedores, segundo a Developer Survey 2025 do Stack Overflow, e o mais popular há dois anos seguidos. Também é um banco de dados que você consegue rodar por conta própria sem dor de cabeça.

Comparação para uma carga de trabalho representativa de uma equipe pequena (4 GB de RAM, ~100 GB de dados, carga de escrita baixa a moderada, região única), com preços de maio de 2026:

O preço sob demanda do RDS db.t4g.medium é de cerca de US$ 0,065 por hora, ou aproximadamente US$ 47,45 por mês só de computação.

Adicione 100 GB de armazenamento gp3 a cerca de US$ 0,115/GB-mês e backups automáticos, e uma instância Single-AZ chega perto de US$ 60/mês. Ative o failover Multi-AZ e a linha de computação praticamente dobra, levando uma configuração de nível de produção a US$ 100/mês ou mais.

Não é uma diferença pequena.

Auto-hospedar sai mais barato porque você faz o trabalho que a fatura do serviço gerenciado pagava: disciplina operacional, plantão e atendimento às 2 da manhã quando o disco enche. A alternativa gerenciada que você está usando como comparação pode ter outro preço mínimo no próximo trimestre. Por isso, faça as contas com a sua própria fatura antes de decidir.

Quando vale a pena auto-hospedar o PostgreSQL?

Auto-hospedar o PostgreSQL em uma VPS faz sentido quando sua equipe tem familiaridade básica com Linux, uma carga de trabalho estável, um conjunto de dados ativo de tamanho previsível e um motivo real para fugir da fatura do serviço gerenciado.

Não funciona quando você não tem capacidade operacional, tem requisitos regulatórios de alta disponibilidade (HA) que não consegue implementar sozinho ou um padrão de uso com picos que se beneficia de escalonamento instantâneo.

Três fatores pesam nessa decisão: custo, privacidade e soberania de dados, e controle.

Onde o auto-hospedado leva clara vantagem:

• Tráfego estável em uma única região, com um conjunto de dados ativo previsível.
• Apps SaaS de pequeno e médio porte, com um banco de dados Postgres e uma equipe à vontade com Linux.
• Cargas de trabalho sensíveis à privacidade, em que o banco de dados não deve ficar no ambiente de terceiros.
• Equipes atentas aos custos, cuja fatura do serviço gerenciado já ultrapassou o ponto em que vale a pena encarar o trabalho operacional.

Onde o gerenciado leva clara vantagem:

• Cargas de trabalho com picos, que se beneficiam de escalar para cima e para baixo instantaneamente.
• Configurações multirregião em que a replicação global é o próprio produto.
• Ambientes regulados que precisam de HA pronta para uso, certificações de conformidade e trilhas de auditoria.
• Equipes sem capacidade operacional sobrando e sem planos de criá-la.

O número de 40% a 60% de economia é muito citado. Preste atenção à data dele.

Em 2021, Rupesh Desai, autor da AWS, documentou que o PostgreSQL no EC2 custava 40% a 60% menos que o RDS com especificações equivalentes. É um dado anterior à maioria das famílias de instâncias atuais do RDS.

A versão atual é a análise de custos da byteiota, publicada no fim de 2025, segundo a qual o RDS é 75% a 88% mais caro do que hardware dedicado equivalente.

O ponto de equilíbrio real está nas horas de operação, não no custo do servidor.

Como escolher o tamanho certo de VPS para o PostgreSQL?

A maioria dos bancos de dados de aplicações em produção roda tranquilamente com 4 GB de RAM e armazenamento NVMe. Conjuntos de dados maiores, muitas conexões simultâneas ou cargas analíticas elevam a exigência para 8 GB, 16 GB ou mais.

A RAM determina quanto do seu conjunto de dados ativo o Postgres consegue manter na memória. Quando as páginas mais acessadas vão para o disco, as consultas ficam lentas. O NVMe importa porque o Postgres é sensível à latência de leitura aleatória das páginas mais acessadas e à taxa de gravação do write-ahead log.

As recomendações comuns de ajuste do PostgreSQL começam com:

• shared_buffers em cerca de 25% da RAM do sistema.
• effective_cache_size em cerca de 50% a 75% da RAM do sistema.
• work_mem dimensionado de forma conservadora, com base na complexidade das consultas simultâneas, e não apenas na RAM total.

Em uma VPS de 4 GB, isso normalmente significa alocar cerca de 1 GB para shared_buffers e deixar memória suficiente para o cache de páginas do Linux guardar os dados acessados com frequência. Esse equilíbrio é parte do motivo pelo qual uma máquina modesta de 4 GB consegue rodar com folga muitas cargas de produção de pequeno e médio porte.

O mapa de planos por carga de trabalho que você precisa conhecer:

Os planos de hospedagem VPS da DreamHost oferecem acesso root, armazenamento NVMe e largura de banda ilimitada, com uma fatura mensal previsível.

Essas são as quatro coisas de que uma carga de trabalho Postgres auto-hospedada depende.

Como instalar o PostgreSQL em uma VPS?

A instalação do PostgreSQL em uma VPS se resume a cinco passos.

1. Provisione a VPS: Escolha um plano com RAM suficiente para o seu conjunto de dados ativo (Stack 8/8 GB para produção). O Ubuntu 24.04 LTS é o sistema operacional recomendado. Acesse via SSH com autenticação por chave, não por senha.
2. Instale pelo repositório oficial do PGDG: O ‘apt install postgresql’ da distribuição fica atrás nas versões principais. Adicione o repositório apt do PGDG e depois ‘sudo apt install postgresql-18.’ Confirme com ‘sudo systemctl status postgresql’
3. Defina a senha do postgres e crie a role da sua aplicação: Execute sudo -i -u postgres, depois psql e então password postgres. Crie uma role dedicada com privilégios mínimos: ‘CREATE ROLE myapp WITH LOGIN PASSWORD '...';’ e ‘CREATE DATABASE myapp_prod OWNER myapp;’
4. Configure o listener corretamente: Abra /etc/postgresql/18/main/postgresql.conf. Defina listen_addresses = ‘localhost’ se a aplicação e o banco de dados estiverem na mesma máquina, ou vincule a um IP privado se a aplicação rodar em outra VPS. Evite vincular o PostgreSQL a 0.0.0.0 em uma interface acessível publicamente. Bots automatizados varrem instâncias expostas do PostgreSQL de forma agressiva e tentam invadi-las por força bruta.
5. Restrinja o ‘pg_hba.conf’ e o UFW: Edite o pg_hba.conf para permitir apenas os IPs de aplicação de que você realmente precisa, com ‘scram-sha-256’ como método de autenticação. Configure o UFW para liberar a porta 5432 apenas para esses mesmos IPs. Use um túnel SSH para as ferramentas de administração (e, por favor, não abra a 5432 para a internet pública).

Teste a partir de outra máquina: psql -h <vps-ip> -U postgres.

Um timeout ou uma conexão recusada vinda de um IP não autorizado geralmente significa que o listener e as regras de firewall estão fazendo o trabalho deles. Se aparecer um pedido de senha a partir da internet pública, alguma coisa está mal configurada. Com o Postgres rodando, a configuração é só metade do trabalho.

Como proteger o PostgreSQL em uma VPS?

A segurança do PostgreSQL em uma VPS funciona em três camadas, além de boas práticas com roles e uma rotina de atualizações.

1. Autenticação: Use scram-sha-256 em novas instalações e remova as regras md5 legadas do pg_hba.conf. A documentação do PostgreSQL agora avisa que o suporte a senhas criptografadas com MD5 está descontinuado e será removido em uma versão futura.
2. Rede: Vincule o PostgreSQL a ‘localhost’, a um IP privado ou a uma interface acessível apenas pelos seus servidores de aplicação. Evite vinculá-lo a uma interface acessível publicamente. Adicione o UFW como camada extra e libere a porta 5432 apenas para IPs de aplicação confiáveis.
3. Criptografia em trânsito: Ative o TLS em qualquer conexão que atravesse um limite de rede. Defina ssl = on no postgresql.conf e use regras hostssl … scram-sha-256 no pg_hba.conf para que os clientes não voltem silenciosamente a conexões sem TLS. Certificados autoassinados são aceitáveis para tráfego interno, desde que os clientes os verifiquem corretamente.
4. Roles: As conexões da aplicação devem usar uma role com privilégios mínimos, apenas com os direitos necessários para os schemas dessa aplicação. O superusuário fica reservado para migrações e emergências.
5. Atualizações: Use o repositório apt do PGDG para ter pacotes atuais do PostgreSQL. Ative as atualizações de segurança automáticas do sistema operacional, mas programe as atualizações do PostgreSQL com cuidado, para que uma reinicialização inesperada não vire o incidente da semana.

Sua checklist de segurança:

• Use apenas scram-sha-256; desative o md5.
• Vincule ‘listen_addresses’ a localhost ou a um IP privado.
• As regras do UFW liberam a 5432 apenas para IPs confiáveis.
• SSL/TLS ativado em toda conexão que atravesse a rede.
• A aplicação se conecta com uma role de privilégios mínimos, nunca como ‘postgres’.
• Atualizações de segurança automáticas ativadas.
• Nenhuma linha ‘host all all 0.0.0.0/0 md5’ em lugar nenhum do ‘pg_hba.conf’. Nunca.

Esse último item é o que serve de alerta.

A porta 5432 exposta publicamente com credenciais fracas é um alvo conhecido de criptomineradores e ataques de força bruta. Bots automatizados varrem continuamente as instâncias expostas do PostgreSQL em busca de contas padrão, senhas vazadas ou regras permissivas no pg_hba.conf.

Instâncias do Postgres acessíveis publicamente e com autenticação fraca costumam ser comprometidas assustadoramente rápido. Um banco de dados exposto diretamente à internet sem controles de rede adequados, TLS e isolamento de roles é o tipo de erro que vira relatório de incidente. E mesmo um banco de dados bem configurado está a uma falha de disco de perder dados.

Como fazer backup e replicar o PostgreSQL em uma VPS?

Os backups do PostgreSQL em uma VPS usam um de três mecanismos, escolhido de acordo com a falha contra a qual você quer se proteger: backups lógicos com pg_dump para portabilidade, backups físicos com pg_basebackup mais arquivamento de WAL para recuperação point-in-time e replicação por streaming para alta disponibilidade.

Os backups lógicos cuidam de migrações, restaurações parciais e atualizações de ambientes de desenvolvimento. Execute pg_dump –format=custom –file=mydb.dump mydb_prod em um cron job diário. O formato custom comprime bem e, assim como o formato directory, permite usar as opções de restauração paralela e seletiva do pg_restore. Envie o dump para um armazenamento de objetos compatível com S3, fora da VPS.

Os backups físicos cuidam de restaurações completas do sistema e da recuperação point-in-time. O pg_basebackup com arquivamento contínuo do Write-Ahead Log (WAL) permite recuperar qualquer momento entre o último backup base e o segmento de WAL mais recente. É a opção de nível de produção quando a tolerância à perda de dados é de segundos, não de horas.

A replicação por streaming é a terceira opção. Uma réplica de leitura em uma segunda VPS funciona como hot standby para cargas com muita leitura ou como destino rápido de failover. Essa configuração de replicação do banco de dados custa uma segunda VPS, mas limita a pior interrupção possível a poucos minutos.

Teste a restauração todo mês. Os serviços gerenciados já trazem tudo isso embutido, e é justamente esse trabalho que você assume em troca da economia da auto-hospedagem. Se você já usa um provedor gerenciado, sair dele é mais simples do que parece.

Como migrar do RDS, Supabase ou Neon para uma VPS?

Você migra de um provedor de Postgres gerenciado para uma VPS em quatro passos.

1. Provisione a VPS de destino: use exatamente a mesma versão principal do Postgres de origem. Instale o PostgreSQL na nova VPS seguindo os passos acima e, em seguida, crie previamente a role e o banco de dados da aplicação.
2. Faça o dump da origem: execute pg_dump –format=custom –no-owner –no-privileges –file=src.dump <source-connection-string>. As flags –no-owner e –no-privileges removem permissões de roles específicas do provedor, que raramente são recriadas sem problemas em um novo host.
3. Restaure no destino: execute pg_restore –dbname=myapp_prod –jobs=4 –no-owner –no-privileges src.dump. Fique de olho nos avisos sobre extensões. RDS, Supabase e Neon costumam ativar extensões que podem não existir no Postgres padrão. Instale extensões compatíveis pelos pacotes do PGDG ou pelo postgresql-contrib antes de restaurar.
4. Troque a string de conexão e verifique: primeiro, aponte um ambiente de staging para a nova VPS, rode sua suíte de testes e valide consultas de produção e fluxos da aplicação representativos antes de trocar a string de conexão de produção. Para aplicações com pouca escrita, uma janela de manutenção curta durante a migração final costuma ser mais simples do que configurar replicação. Mantenha o banco de dados de origem online e somente leitura por alguns dias, como alternativa caso precise reverter.

O que muda de um provedor para outro?

1. Do RDS: as roles específicas do RDS (“rds_superuser”, “rdsadmin”) não existem no Postgres padrão; as flags –no-owner e –no-privileges resolvem a maior parte disso. Algumas extensões gerenciadas pelo RDS precisam ser instaladas manualmente, e a transferência de dados para fora da AWS durante o dump é cobrada.
2. Do Supabase: o Postgres é um Postgres de verdade, mas as camadas de autenticação, armazenamento e edge do Supabase não são migradas. O esquema da sua aplicação, sim. Substitua essas camadas por equivalentes auto-hospedados antes de fazer a migração final.
3. Do Neon: o branching deixa de existir após a migração; planeje backups no lugar dele. O dump e a restauração são simples, mas hábitos operacionais como branches instantâneos precisam de um fluxo de trabalho substituto.

A migração em si costuma levar menos tempo do que escolher o plano de VPS. O tempo de inatividade realista é de minutos para bancos de dados pequenos e maior para os grandes, por causa do replay do WAL. A maioria das instalações para por aqui, mas existe um cenário que leva você um pouco mais longe…

Quando adicionar o PgBouncer ou ficar com o Postgres puro?

A maioria das aplicações em uma VPS de 4 GB não precisa de um pool de conexões no início. Adicione o PgBouncer quando as conexões simultâneas passarem de cerca de 100 ou quando sua stack abrir uma nova conexão a cada requisição.

As conexões do PostgreSQL são pesadas porque cada uma é um processo completo do sistema operacional. Com 4 GB de RAM, você não quer centenas de conexões ociosas consumindo memória. O pooler mantém as conexões caras do Postgres de um lado e distribui conexões leves e de curta duração para sua aplicação do outro.

Dois modos de pooling importam:

• Pooling por sessão: cada cliente recebe uma conexão com o servidor durante toda a sessão. É seguro para qualquer aplicação, não muda a semântica e oferece um ganho menor de throughput.
• Pooling por transação: cada cliente recebe uma conexão com o servidor durante uma transação. O ganho de throughput é grande. Você perde recursos que dependem do estado da sessão (prepared statements, advisory locks, “LISTEN”/“NOTIFY”), a menos que a aplicação tenha sido escrita para lidar com isso.

A maioria dos apps SaaS pequenos com um ORM que já usa pool de conexões funciona bem sem o PgBouncer, até deixar de funcionar. O sinal de que você passou do limite são erros “FATAL: too many connections” ou pressão de memória causada por conexões ociosas.

Instale com sudo apt install pgbouncer, configure /etc/pgbouncer/pgbouncer.ini com a lista de bancos de dados e o modo de pool e, depois, aponte a aplicação para o PgBouncer na porta 6432.

Sim, você vai saber quando precisar dele.

A decisão final

A diferença de custo é real o bastante para valer a pena fazer as contas com a sua própria fatura. Mas a configuração não é a parte difícil.

A parte difícil é o trabalho operacional que a fatura do serviço gerenciado estava pagando: backups, testes de restauração, atualizações e monitoramento.

De qualquer forma, respire fundo antes de abrir a próxima fatura.

Perguntas frequentes sobre PostgreSQL em uma VPS