PostgreSQL Autogerido em um VPS: Escape do Preço de DB Gerenciado

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

O export de snapshot que você esqueceu. A taxa de saída do ambiente de staging que executou um ‘pg_dump’ na última terça-feira.

Ninguém abre a fatura do seu banco de dados gerenciado esperando que seja barato.

Mas, caramba.

A diferença entre “Postgres por $25 ao mês” e o que aparece no cartão tornou-se grande, e um VPS de 4 GB pelo preço de um único complemento Supabase agora executa seu banco de dados inteiro com espaço de sobra para o sistema operacional armazenar em cache as páginas mais acessadas.

Hospedar um banco de dados Postgres de produção não é mais o pesadelo operacional que já foi. O repositório PostgreSQL Global Development Group (PGDG) é sólido; instalações modernas de PostgreSQL (v14+) usam por padrão a criptografia de senha SCRAM-SHA-256, com o legado MD5 oficialmente descontinuado a partir da v18. As razões pelas quais as pessoas continuam a usar RDS, Supabase ou Neon hoje são operacionais, não técnicas.

Estamos falando sobre faturas reais, custos operacionais reais e como é realmente o hosting moderno de Postgres.

Quanto Custa Realmente Hospedar o PostgreSQL em um VPS por Conta Própria?

O PostgreSQL auto-hospedado em um VPS de 4 GB geralmente opera por uma fração do preço equivalente de RDS, Supabase Pro ou Neon Scale, uma vez que armazenamento, backups e saída são incluídos na fatura gerenciada.

PostgreSQL é o banco de dados usado por 55,6% dos desenvolvedores, segundo a Pesquisa de Desenvolvedores de 2025 do Stack Overflow, o mais popular pelos últimos dois anos consecutivos. É também o banco de dados que você pode gerenciar confortavelmente por conta própria.

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

Opção	Computação	Armazenamento	Egresso após o limite gratuito	Melhor para
Auto-hospedado em um VPS de 4 GB	Preço fixo do plano	Geralmente incluído	Geralmente não medido ou com alto limite	Trabalhos constantes, equipes sensíveis a custos confortáveis com Linux
AWS RDS db.t4g.medium	$47.45/mês somente computação	~$0.115/GB-mês gp3	~$0.09/GB internet/fora da região	Equipes que desejam backups gerenciados, failover e operações nativas da AWS
Supabase Pro	$25/mês base + uso	$0.125/GB disco do banco de dados além dos 8 GB incluídos	$0.09/GB após 250 GB	Aplicações que necessitam de Postgres, autenticação, armazenamento e tempo real em um único stack
Neon Scale	$0.222 por CU/hora	$0.35 por GB/mês	Medido por uso	Fluxos de trabalho de desenvolvimento com picos, muitos previews e ramificações

O preço sob demanda do RDS db.t4g.medium é aproximadamente $0.065 por hora, ou cerca de $47.45 por mês apenas para computação.

Adicione 100 GB de armazenamento gp3 por aproximadamente $0,115/GB-mês e backups automatizados, e uma caixa Single-AZ fica próxima de $60/mês. Ative a falha Multi-AZ e a linha de computação dobra aproximadamente, elevando uma configuração de nível de produção para $100/mês ou mais.

Essa não é uma pequena lacuna.

Self-hosting é mais barato porque você faz o trabalho pelo qual a conta gerenciada estava pagando. Disciplina de operações, de plantão, às 2 da manhã, quando o disco enche. A alternativa de DB gerenciado com a qual você está comparando pode ter um limite diferente no próximo trimestre, então faça as contas com sua própria conta antes de se comprometer.

Quando Faz Sentido Auto-Hospedar PostgreSQL?

Autogerenciar o PostgreSQL em um VPS faz sentido quando você tem um conhecimento básico de Linux na equipe, uma carga de trabalho estável, um tamanho de conjunto de trabalho previsível e uma razão real para evitar a conta gerenciada.

Não funciona quando você não tem capacidade de operação, requisitos de HA regulados que você não pode construir por si mesmo, ou um padrão de picos que se beneficia de uma escala instantânea.

Três coisas impulsionam essa decisão. Custo, privacidade e soberania dos dados, e controle.

Onde a auto-hospedagem vence claramente:

• Tráfego constante em uma única região com um conjunto de trabalho previsível.
• Aplicações SaaS de pequeno a médio porte com um banco de dados Postgres e uma equipe confortável com Linux.
• Cargas de trabalho sensíveis à privacidade onde o banco de dados não deve estar na tenência de outra pessoa.
• Equipes conscientes dos custos cuja fatura gerenciada ultrapassou o limiar de problemas operacionais.

Onde a gestão sai claramente vencedora:

• Cargas de trabalho com picos que se beneficiam de escalabilidade instantânea para aumento e redução.
• Configurações multi-região onde a replicação global é o produto.
• Ambientes regulados que necessitam de HA pronta para uso, certificados de conformidade e registros de auditoria.
• Equipes sem capacidade operacional disponível e sem plano para desenvolvê-la.

O número de economia de custos de 40% a 60% é citado frequentemente. Date-o com cuidado.

A partir de 2021, o autor da AWS Rupesh Desai documentou o PostgreSQL no EC2 rodando 40% a 60% mais barato do que o RDS com especificações equivalentes, mais antigo do que a maioria das famílias de instâncias RDS atuais.

A versão atual é a análise de custo-benefício da byteiota, publicada no final de 2025, que diz que o RDS é 75% a 88% mais caro do que o hardware dedicado equivalente.

O ponto de equilíbrio honesto são as horas operacionais, não o custo do servidor.

Como Escolher o Tamanho Certo de VPS para PostgreSQL?

A maioria dos bancos de dados de aplicações em produção funciona confortavelmente com 4 GB de RAM e armazenamento NVMe. Conjuntos de dados maiores, conexões concorrentes intensas ou cargas de trabalho analíticas aumentam a necessidade para 8 GB ou 16 GB e acima.

A RAM determina quanto do seu conjunto de trabalho o Postgres pode manter na memória; uma vez que as páginas ativas passem para o disco, as consultas desaceleram. NVMe é importante porque o Postgres é sensível à latência de leitura aleatória para páginas ativas e ao desempenho de limpeza para o registro de pré-escrita.

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

• shared_buffers a aproximadamente 25% da RAM do sistema.
• effective_cache_size a aproximadamente 50%-75% da RAM do sistema.
• work_mem dimensionado de forma conservadora — baseado na complexidade da consulta concorrente, não somente na RAM total.

Em um VPS de 4 GB, isso geralmente significa alocar cerca de 1 GB para shared_buffers, deixando memória suficiente para o cache de páginas do Linux armazenar dados acessados frequentemente. Esse equilíbrio é parte do motivo pelo qual uma modesta caixa de 4 GB pode executar confortavelmente muitas cargas de trabalho de produção de pequeno a médio porte.

O mapa de plano para carga de trabalho que você precisa conhecer:

Categoria de RAM	Carga de Trabalho Típica	Plano de Stack Recomendado
2 GB	Ambientes de desenvolvimento, projetos laterais com baixo tráfego	Abaixo da linha de base
4 GB	Bancos de dados de aplicações em produção na maioria das vezes	Stack 4
8 GB	Conjuntos de dados maiores, mais conexões simultâneas	Stack 8
16 GB+	Postgres juntamente com outros serviços pesados, análises	Stack 16

Os Planos de VPS Hosting da DreamHost dão-te acesso root, armazenamento NVMe e largura de banda ilimitada em uma conta mensal previsível.

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

Como Instalar o PostgreSQL em um VPS?

Você instala o PostgreSQL em um VPS em cinco passos compactados.

1. Provisione o VPS: Escolha um plano com RAM suficiente para seu conjunto de trabalho (Stack 4/4 GB é a linha de base). Ubuntu 24.04 LTS é o sistema operacional recomendado. Conecte-se via SSH com autenticação baseada em chave, não com senha.
2. Instale a partir do repositório oficial PGDG: O distro ‘apt install postgresql’ está atrasado em versões principais. Adicione o repositório apt PGDG, então ‘sudo apt install postgresql-18.’ Confirme com ‘sudo systemctl status postgresql’
3. Defina a senha do postgres e crie seu papel de aplicativo: Execute sudo -i -u postgres, em seguida, psql, depois password postgres. Crie um papel dedicado de menor privilégio: ‘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 o aplicativo e o banco de dados compartilham a máquina, ou vincule a um IP privado se o aplicativo for executado em um VPS separado. Evite vincular o PostgreSQL a 0.0.0.0 em uma interface publicamente acessível. Instâncias de PostgreSQL expostas são agressivamente escaneadas e forçadas brutas por bots automatizados.
5. Proteja ‘pg_hba.conf’ e UFW: Edite pg_hba.conf para permitir apenas os IPs da aplicação que você realmente precisa, com ‘scram-sha-256’ como método de autenticação. Configure o UFW para permitir a porta 5432 apenas para esses mesmos IPs. Use túnel SSH para ferramentas administrativas (e, por favor, não abra o 5432 para a internet pública).

Tente isso de outra máquina: psql -h <vps-ip> -U postgres.

Um tempo esgotado ou uma conexão recusada de um IP não autorizado geralmente significa que o seu ouvinte e as regras do firewall estão fazendo seu trabalho. Um prompt de senha da internet pública significa que algo está configurado incorretamente. Uma vez que o Postgres está em funcionamento, a configuração é apenas metade do trabalho.

Como Você Protege PostgreSQL em um VPS?

O PostgreSQL em um VPS é protegido em três camadas, além da higiene de funções e da frequência de atualizações.

1. Autenticação: Use scram-sha-256 para novas instalações e remova regras legadas md5 de pg_hba.conf. A documentação do PostgreSQL agora alerta que o suporte a senhas criptografadas com MD5 está obsoleto e será removido em uma futura versão.
2. Rede: Vincule o PostgreSQL ao ‘localhost’, um IP privado ou uma interface acessível apenas pelos seus servidores de aplicação. Evite vinculá-lo a uma interface acessível publicamente. Adicione o UFW por cima e permita a porta 5432 apenas de IPs de aplicação confiáveis.
3. Criptografia em trânsito: Ative o TLS para qualquer conexão que atravesse um limite de rede. Defina ssl = on em postgresql.conf, em seguida, use regras hostssl … scram-sha-256 em pg_hba.conf para que os clientes não possam retroceder silenciosamente para conexões não TLS. Certificados autoassinados são aceitáveis para tráfego interno se os clientes os verificarem adequadamente.
4. Funções: Conexões de aplicativos devem usar uma função de menor privilégio com apenas os direitos necessários para os esquemas dessa aplicação. O superusuário é para migrações e emergências.
5. Atualizações: Use o repositório apt do PGDG para pacotes atuais do PostgreSQL. Habilite atualizações de segurança automáticas para o sistema operacional, mas agende atualizações do PostgreSQL deliberadamente para que um reinício surpresa não se torne o incidente da semana. 

Sua lista de verificação de segurança:

• Use somente scram-sha-256; desative md5.
• Vincule ‘listen_addresses’ ao localhost ou IP privado.
• Regras do UFW permitem 5432 apenas de IPs confiáveis.
• SSL/TLS ativado para qualquer conexão que cruze a rede.
• O aplicativo se conecta como um papel com o mínimo de privilégios, nunca como ‘postgres’.
• Atualizações de segurança não supervisionadas ativadas.
• Nenhuma linha ‘host all all 0.0.0.0/0 md5’ em ‘pg_hba.conf’, nunca.

Essa última observação é o conto cautelar.

Porta pública 5432 com credenciais fracas é um alvo conhecido de mineradores de criptomoedas e ataques de força bruta. Instâncias expostas de PostgreSQL são continuamente escaneadas por bots automatizados que procuram contas padrão, senhas vazadas ou regras permissivas no pg_hba.conf.

Instâncias de Postgres publicamente acessíveis com autenticação fraca são frequentemente comprometidas de forma surpreendentemente rápida. Um banco de dados exposto diretamente à internet sem controles de rede adequados, TLS e isolamento de funções é o tipo de erro que se transforma em um relatório de incidente. Um banco de dados configurado corretamente ainda está a uma falha de disco de perder dados.

Como Fazer Backup E Replicar PostgreSQL Em Um VPS?

Os backups do PostgreSQL em um VPS utilizam um dos três mecanismos, escolhido de acordo com a falha que você está protegendo. Backups lógicos por meio de pg_dump para portabilidade, backups físicos por meio de pg_basebackup além de arquivamento WAL para recuperação em um ponto específico do tempo, e replicação em streaming para alta disponibilidade.

Os backups lógicos gerenciam migrações, restaurações parciais e atualizações de desenvolvimento. Execute pg_dump –format=custom –file=mydb.dump mydb_prod a partir de um Cron Job diário. O formato personalizado comprime bem e, junto com o formato de diretório, suporta as opções de restauração paralela e seletiva do pg_restore. Envie o dump para o armazenamento de objetos fora do VPS (DreamObjects, compatível com S3).

Os backups físicos lidam com restaurações completas do sistema e recuperação em um ponto específico no tempo. pg_basebackup mais o arquivamento contínuo do Log Antecipado de Escrita (WAL) permitem recuperar qualquer momento entre o último backup base e o segmento WAL mais recente, a opção de nível de produção quando a tolerância à perda de dados é de segundos, não horas.

A replicação por streaming é a terceira opção. Uma réplica de leitura em um segundo VPS é um standby imediato para cargas de trabalho intensas em leitura ou um alvo rápido de failover. A configuração de replicação de banco de dados custa um segundo VPS, mas limita seu pior caso de indisponibilidade a minutos.

Mecanismo	O Que Ele Oferece	Custo Associado
pg_dump + cron + armazenamento fora do VPS	Backup lógico diário, portátil	Latência de restauração, não é ponto no tempo
pg_basebackup + arquivamento WAL	Backup físico com recuperação ponto a ponto	Complexidade operacional e de armazenamento
Replicação em streaming	Standby quente, objetivo de ponto de recuperação (RPO) quase zero, escalonamento de leitura	Segundo VPS mais gerenciamento de replicação

Restauração-teste mensal. Serviços gerenciados incorporam tudo isso, e é parte do que a economia de auto-hospedagem está recuperando. Se você já está em um provedor gerenciado, o caminho para sair é mais simples do que parece.

Como Migrar do RDS, Supabase ou Neon para um VPS?

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

1. Provisionar o VPS destino: Igualar exatamente a versão maior do Postgres da fonte. Instale o PostgreSQL no novo VPS seguindo os passos acima, depois pré-crie o papel da aplicação e o banco de dados.
2. Dump da fonte: Execute pg_dump –format=custom –no-owner –no-privileges –file=src.dump <source-connection-string>. As flags –no-owner e –no-privileges removem concessões de papel específicas do fornecedor que raramente são recriadas de forma limpa em um novo host.
3. Restaurar para o destino: Execute pg_restore –dbname=myapp_prod –jobs=4 –no-owner –no-privileges src.dump. Fique atento a avisos de extensões. RDS, Supabase e Neon frequentemente ativam extensões que podem não existir em Postgres padrão. Instale extensões compatíveis dos pacotes PGDG ou postgresql-contrib antes de restaurar.
4. Substituição e verificação de string de conexão: Aponte um ambiente de staging para o novo VPS primeiro, execute sua suíte de testes, depois valide queries de produção representativas e fluxos de aplicação antes de mudar a string de conexão de produção. Para aplicações com baixa escrita, uma janela de manutenção curta durante o corte final é muitas vezes mais simples do que configurar replicação. Mantenha o banco de dados de origem online e somente leitura por vários dias como um alvo de rollback.

Quais mudanças por provedor?

1. De RDS: Papéis específicos do RDS (‘rds_superuser,’ ‘rdsadmin’) não existem em Postgres puro; –no-owner e –no-privileges lidam com a maior parte. Algumas extensões gerenciadas pelo RDS precisam de instalação manual, e a saída de dados da AWS durante o dump é faturável.
2. De Supabase: O Postgres é real, mas as camadas de autenticação, armazenamento e edge do Supabase não migram. Seu esquema de aplicação migra. Substitua essas camadas por equivalentes auto-hospedados antes de fazer a transição.
3. De Neon: A ramificação desaparece após a migração; planeje backups em vez disso. Dump e restauração são diretos, mas hábitos operacionais como ramificações instantâneas precisam de um fluxo de trabalho de substituição.

A própria migração geralmente leva menos tempo do que escolher o plano VPS. O tempo de inatividade realístico é de minutos para pequenas bases de dados, e mais longo com a reprodução WAL para as grandes. A maioria das instalações para aqui, mas há um cenário que te leva além…

Quando Deve Adicionar PgBouncer ou Manter o Postgres Vanilla?

A maioria dos aplicativos em um VPS de 4 GB não precisa de um pool de conexões no início. Adicione PgBouncer quando as conexões simultâneas excederem aproximadamente 100, ou quando sua pilha de aplicativos abrir uma nova conexão por solicitação.

As conexões 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 do seu lado e distribui conexões baratas e de curta duração para o seu aplicativo do outro.

Dois modos de pooling importam:

• Agrupamento de sessões: Cada cliente recebe uma conexão de servidor para a sessão. Seguro para qualquer aplicativo, sem mudança de semântica, ganho de produtividade menor.
• Agrupamento de transações: Cada cliente recebe uma conexão de servidor para uma transação. Grande ganho de produtividade. Você perde recursos que dependem do estado da sessão (instruções preparadas, bloqueios consultivos, ‘LISTEN’/’NOTIFY’) a menos que o aplicativo seja escrito para esperar isso.

A maioria dos pequenos aplicativos SaaS com um ORM com pool de conexões funciona bem sem o PgBouncer até que não funcione mais. O sinal de que você ultrapassou o limite é os erros ‘FATAL: too many connections’ ou pressão de memória por conexões inativas.

Instale-o com sudo apt install pgbouncer, configure /etc/pgbouncer/pgbouncer.ini com sua lista de bancos de dados e modo de pool, em seguida, direcione o aplicativo para o PgBouncer na porta 6432.

Sim, você saberá quando precisar.

Tomando a Decisão Final

A diferença de custo é real o suficiente para justificar 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 pelo qual a conta gerenciada estava pagando. Backups, exercícios de restauração, atualizações e monitoramento.

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

Perguntas Frequentes Sobre PostgreSQL em um VPS

Quanta RAM o PostgreSQL precisa em um VPS?

PostgreSQL funciona com 1 a 2 GB para pequenas cargas de trabalho e confortavelmente em 4 GB para a maioria dos bancos de dados de aplicações em produção. Conjuntos de dados mais pesados, mais conexões simultâneas ou cargas de trabalho analíticas elevam a necessidade para 8 GB ou mais.

Posso executar PostgreSQL em um VPS de 2 GB?

Sim, você pode executar PostgreSQL em um VPS de 2 GB para pequenos aplicativos, ambientes de desenvolvimento e projetos paralelos de baixo tráfego. Uma caixa de 2 GB deixa pouco espaço para cache, então o desempenho das consultas diminui à medida que seus dados ultrapassam a memória. Para cargas de trabalho de produção, 4 GB é a linha de base mais segura.

É mais barato hospedar o PostgreSQL em um VPS do que em RDS ou Supabase?

Sim, hospedar você mesmo o PostgreSQL em um VPS é mais barato do que o RDS ou Supabase para a maioria dos workloads em estado constante. Um VPS de 4 GB geralmente opera por uma fração do equivalente ao RDS, Supabase Pro, ou especificações Neon Scale, uma vez considerados armazenamento, backups e saída de dados. A contrapartida é que você opera o banco de dados por conta própria.

Como expor o PostgreSQL em um VPS de forma segura?

Não exponha a porta 5432 à internet pública. Vincule o PostgreSQL ao localhost ou a um IP privado, exija autenticação scram-sha-256 e ferramentas administrativas de túnel SSH em vez de abrir a 5432 para o seu laptop. A porta 5432 pública com autenticação fraca é um alvo conhecido de criptomineradores.

Preciso Usar Docker Para PostgreSQL Em Um VPS?

Não, Docker não é necessário. O repositório oficial PGDG apt instala o PostgreSQL como um serviço nativo do sistema, que é a configuração mais simples para produção. Docker é razoável se você já estiver executando outros contêineres.

Como faço backup do PostgreSQL em um VPS?

Execute pg_dump –format=custom em uma agenda de Cron Job diária e armazene a saída fora do VPS em armazenamento de objetos compatível com S3. Utilize pg_basebackup mais arquivamento WAL para recuperação pontual quando segundos de perda de dados importarem. Teste de restauração mensalmente.

Qual Plano Devo Escolher Para Hospedar o PostgreSQL Por Conta Própria no DreamHost?

O plano VPS Stack 4 da DreamHost (4 GB de RAM) é a base recomendada para a maioria dos bancos de dados de aplicações em produção. Escolha o Stack 8 (8 GB) para conjuntos de dados maiores ou alta concorrência, e o Stack 16 para Postgres junto com outros serviços que consomem muitos recursos.

Devo usar PgBouncer com PostgreSQL em um pequeno VPS?

A maioria dos aplicativos em um VPS de 4 GB não precisa de PgBouncer no início. Adicione um pool de conexões quando as conexões concorrentes se aproximarem de 100, ou quando seu aplicativo abrir uma nova conexão por solicitação.