Todo projeto que sai da fase de protótipo esbarra na mesma pergunta: onde o banco de dados vai morar? A resposta parece puramente técnica, mas mexe com orçamento, com a rotina do time e até com o sono de quem fica de plantão. Para pequenas equipes, com três, cinco ou dez pessoas e nenhum DBA dedicado, a decisão pesa ainda mais, porque cada hora gasta com infraestrutura sai do tempo que poderia ir para o produto.
Dois caminhos aparecem com mais frequência. O primeiro é instalar e administrar PostgreSQL em VPS, ou seja, num servidor virtual que a própria equipe controla do sistema operacional até o último parâmetro. O segundo é contratar um banco de dados gerenciado, em que o provedor entrega uma instância pronta e cuida de backup, atualização e failover. À primeira vista, o segundo parece sempre mais seguro e o primeiro sempre mais barato. Na prática, a conta tem mais camadas do que isso.
Neste artigo, comparamos os dois modelos com critérios que importam no dia a dia: custo real, tempo de operação, desempenho, segurança, recuperação de falhas e liberdade de configuração. No final, você encontra cenários concretos, erros comuns e uma regra simples para decidir sem depender de modismo.
O que significa cada modelo
O PostgreSQL é um sistema de banco de dados relacional de código aberto, respeitado pela aderência ao padrão SQL, pelo suporte nativo a JSON, pelas transações confiáveis e por extensões como PostGIS e pg_trgm. O software é o mesmo nos dois caminhos. O que muda é quem opera o banco no dia a dia.
Instalação própria em servidor virtual
Nesse formato, a equipe aluga um VPS, instala o PostgreSQL pelo repositório da distribuição e assume tudo o que vem depois: arquivos de configuração, usuários, firewall, atualizações, cópias de segurança, monitoramento e recuperação em caso de falha. Em troca, recebe acesso root, liberdade para escolher a versão e as extensões e um custo fixo e fácil de prever, já que o valor mensal do servidor não muda com o volume de leituras e escritas.
Serviço gerenciado
Aqui o provedor entrega a instância pronta. A equipe recebe host, porta, usuário e senha, e o sistema operacional fica fora do alcance. Um banco de dados gerenciado costuma incluir backups automáticos, janelas de manutenção, atualização de versões menores, painel de métricas e, nos planos mais completos, réplica com failover automático. O acesso de superusuário é limitado, e as extensões disponíveis seguem uma lista definida pelo provedor.
Vale pensar nisso como um modelo de responsabilidade compartilhada. O provedor responde pela máquina, pelo sistema e pela disponibilidade da plataforma. A equipe continua responsável pelo esquema, pelas consultas, pelos índices e pelas permissões. Uma consulta mal escrita trava um banco gerenciado exatamente como trava um banco instalado à mão.
Como cada modelo funciona na prática
Rota do VPS, etapa por etapa
Quem escolhe o servidor virtual percorre, em linhas gerais, o caminho abaixo. Nenhuma das etapas é difícil sozinha, mas todas precisam de atenção e de alguém responsável por elas.
- Dimensionar o servidor. Para uma aplicação pequena, 2 vCPU, de 4 a 8 GB de RAM e disco NVMe costumam bastar no início. O disco merece mais atenção que o processador, porque banco de dados vive de leitura e escrita rápidas.
- Instalar o PostgreSQL. Em Ubuntu ou Debian, basta um comando:
sudo apt install postgresql postgresql-contrib
- Ajustar a memória. A configuração padrão é conservadora e pensada para máquinas modestas. Um ponto de partida usual reserva cerca de 25% da RAM para shared_buffers e informa ao planejador, em effective_cache_size, algo entre 50% e 75% da memória. Para conferir o valor atual:
sudo -u postgres psql -c "SHOW shared_buffers;"
- Fechar o acesso. Defina listen_addresses, regras no arquivo pg_hba.conf e um firewall que libere a porta 5432 apenas para o servidor da aplicação:
sudo ufw allow from 203.0.113.10 to any port 5432
- Configurar o backup do PostgreSQL. Em bases pequenas, um dump diário resolve:
pg_dump -Fc -U app_user -h localhost nome_do_banco > backup.dump
Para voltar a um ponto exato no tempo, entra o arquivamento de WAL com ferramentas como pgBackRest ou Barman. Em qualquer caso, a cópia precisa ficar fora do servidor do banco.
Falta ainda o monitoramento: espaço em disco, número de conexões, consultas lentas (a extensão pg_stat_statements ajuda bastante) e alertas que acordem alguém antes de o disco encher.
Rota do serviço gerenciado
No serviço gerenciado, o roteiro encolhe. Você escolhe a versão do PostgreSQL e o tamanho da instância, define quem pode se conectar (lista de IPs permitidos ou rede privada), cria o banco e o usuário e copia a string de conexão para a aplicação, de preferência com TLS ativo. Depois, configura a janela de manutenção e o período de retenção dos backups. Em geral, o processo leva menos de meia hora, e o banco já nasce com cópias automáticas e métricas visíveis no painel.
Quem faz o quê
A tabela mostra como as responsabilidades se dividem em cada modelo.
| Tarefa | PostgreSQL no VPS | Serviço gerenciado |
|---|---|---|
| Instalação e escolha da versão | Equipe | Provedor (versões de uma lista) |
| Atualizações do sistema operacional | Equipe | Provedor |
| Atualizações menores do PostgreSQL | Equipe | Provedor, em janela de manutenção |
| Cópias de segurança | Equipe monta e agenda | Provedor executa; equipe define a retenção |
| Teste de restauração | Equipe | Equipe (o provedor não testa por você) |
| Réplica e failover | Equipe configura e mantém | Provedor, conforme o plano |
| Ajuste fino de parâmetros | Total | Parcial, dentro dos limites do provedor |
| Extensões | Qualquer uma compatível | Somente as liberadas |
| Esquema, índices e consultas | Equipe | Equipe |
Vantagens e desvantagens de cada caminho
Onde o VPS se destaca
- Custo previsível. O valor mensal do servidor é fixo, sem cobrança separada por armazenamento extra, operações de disco ou tráfego de saída.
- Controle total. Qualquer extensão, qualquer parâmetro, qualquer versão, inclusive as recém-lançadas.
- Convivência com a aplicação. Banco e aplicação podem rodar na mesma máquina ou na mesma rede privada, o que reduz a latência a quase zero.
- Portabilidade. Um dump e um script de instalação bastam para levar tudo a outro provedor.
- Aprendizado. A equipe entende o que acontece por baixo, e esse conhecimento ajuda a diagnosticar problemas de desempenho mais tarde.
Onde o VPS cobra seu preço
O custo escondido é o tempo de gente. Instalar leva uma tarde, mas manter leva anos: aplicar correções de segurança, revisar o crescimento do disco, validar backups, planejar a troca de versão principal. O PostgreSQL publica versões menores em ciclo trimestral e dá suporte a cada versão principal por cinco anos, o que significa uma migração planejada de tempos em tempos. Se ninguém na equipe gosta desse tipo de tarefa, ela tende a ser adiada até virar problema.
Onde o serviço gerenciado se destaca
O ganho principal é a rotina que desaparece. Backups acontecem sozinhos, as correções chegam na janela combinada, a réplica sobe com alguns cliques e o painel mostra métricas sem configuração extra. Para um time que quer publicar funcionalidades e dormir tranquilo, isso vale muito. Outro ponto a favor: a recuperação de uma falha de hardware costuma ser responsabilidade do provedor, e não de quem estiver de plantão na madrugada.
Onde o serviço gerenciado pesa
A fatura cresce em várias frentes: tamanho da instância, armazenamento, réplicas, tráfego de saída e, em alguns provedores, operações de disco provisionadas. Um banco de 100 GB com réplica pode custar bem mais do que um VPS equivalente. Além disso, o acesso de superusuário é restrito, algumas extensões não estão disponíveis e certos recursos proprietários do provedor, se usados, dificultam uma futura mudança de plataforma.
Limitações e riscos que merecem atenção
Nenhum dos modelos é imune a falhas. Os riscos mudam de lugar, e conhecê-los de antemão evita surpresas.
No VPS, o maior perigo é o ponto único de falha. Se o servidor, o disco e os backups estiverem na mesma máquina, uma única pane leva tudo junto. Também pesa a concentração de conhecimento: quando só uma pessoa sabe como o banco foi configurado, a saída dela vira um risco operacional. E há a segurança. Uma porta 5432 aberta para a internet inteira recebe tentativas de login em poucas horas, e senhas fracas cedem rápido.
No serviço gerenciado, os riscos são outros. A janela de manutenção acontece quando o provedor decide (dentro de um intervalo que você escolhe), e uma reinicialização pode derrubar conexões da aplicação que não sabe reconectar. A distância entre aplicação e banco também importa: se o app está em uma região e o banco em outra, a latência de cada consulta aumenta e o tráfego entre regiões entra na conta. Por fim, vale olhar a questão legal. Para dados pessoais de brasileiros, a LGPD exige cuidado com o tratamento e com a localização das informações, então confira em que região o provedor mantém o banco e quais garantias contratuais oferece.
Um ponto vale para os dois lados: backup que nunca foi restaurado é uma hipótese, e não uma garantia. Testar a restauração em um ambiente separado, de tempos em tempos, é o hábito que mais evita desgosto.
Cenários práticos: qual escolha combina com cada situação
Cenário 1. Startup com MVP e duas pessoas de desenvolvimento
O time precisa lançar rápido, tem pouca experiência com administração de banco e não pode perder dados de clientes pagantes. Aqui o serviço gerenciado costuma ser a escolha mais segura: backups automáticos e failover simples liberam as duas pessoas para cuidar do produto. Se o orçamento aperta demais, um VPS pequeno funciona, desde que alguém assuma por escrito a responsabilidade pelos backups e pelo teste de restauração.
Cenário 2. Software house com vários projetos pequenos
Uma agência que mantém dez ou quinze sistemas de clientes, cada um com um banco modesto, sofreria com dez faturas de serviço gerenciado. Um servidor virtual bem dimensionado, com bancos separados por projeto, scripts padronizados de instalação e backup e monitoramento centralizado, entrega custo baixo e rotina repetível. Nesse caso, um VPS da Serverspace com disco rápido e rede privada atende bem a maioria dos projetos, e o servidor cresce conforme a carga aumenta.
Cenário 3. E-commerce ou SaaS em que cada hora fora do ar custa dinheiro
Quando a receita depende da disponibilidade e não existe um DBA, a prioridade é reduzir o tempo de recuperação. Um serviço gerenciado com réplica e failover automático cobre esse requisito sem exigir que alguém monte e teste um cluster por conta própria. O custo é maior, mas costuma ser menor do que uma tarde de loja parada na Black Friday.
Cenário 4. Time com um profissional de infraestrutura experiente
Se a equipe já tem alguém confortável com Linux, automação e PostgreSQL, e a carga é previsível, o VPS entrega mais desempenho por real investido. Isso fica ainda mais evidente quando o projeto depende de extensões específicas, de parâmetros incomuns ou de uma versão do PostgreSQL que o serviço gerenciado ainda não oferece.
Cenário 5. Abordagem mista
Muitos times usam o servidor virtual para desenvolvimento e homologação, onde a perda de dados não dói, e reservam o serviço gerenciado para a produção. Assim o time pratica a administração do banco sem arriscar o ambiente crítico, e a migração para produção continua simples, porque o PostgreSQL é o mesmo nos dois lados.
Erros comuns ao escolher e operar
Alguns tropeços se repetem em quase toda equipe. A tabela reúne os mais frequentes, com o sintoma que costuma denunciar cada um e o caminho para corrigir.
| Sintoma | Causa provável | Solução |
|---|---|---|
| Erro "too many connections" em horários de pico | Cada instância da aplicação abre muitas conexões, e o limite padrão de max_connections é 100 | Usar um pooler como o PgBouncer e revisar o tamanho do pool na aplicação |
| Banco parado por falta de espaço em disco | Logs e arquivos WAL acumulados, sem alerta de capacidade | Alertas a partir de 80% de uso, rotação de logs e revisão de slots de replicação esquecidos |
| Restauração falha justamente no dia da emergência | O backup do PostgreSQL existe, mas ninguém nunca o restaurou | Restaurar em ambiente separado todo mês e registrar o tempo gasto |
| Fatura do serviço gerenciado sobe sem explicação | Armazenamento com crescimento automático, réplicas esquecidas ou tráfego de saída | Revisar a cobrança por item e remover o que não é usado |
| Tentativas de login de IPs desconhecidos nos logs | Porta 5432 aberta para qualquer origem | Liberar apenas IPs conhecidos, usar rede privada ou VPN e exigir TLS |
| Consultas lentas após o crescimento dos dados | Falta de índices e parâmetros de memória nos valores padrão | Analisar com pg_stat_statements e EXPLAIN, criar índices e ajustar a memória |
Há ainda um erro de raciocínio que merece destaque: comparar apenas o preço mensal. O VPS parece barato quando se ignora o tempo de manutenção, e o serviço gerenciado parece caro quando se ignora o custo de uma indisponibilidade. A comparação honesta soma a mensalidade, as horas de operação e o prejuízo de uma falha prolongada.
Qual caminho escolher na prática
Para decidir, vale responder a cinco perguntas com franqueza:
- Existe alguém na equipe que aceita cuidar do banco, com tempo reservado para isso?
- Quanto custa, em dinheiro e em reputação, uma hora de indisponibilidade?
- O projeto precisa de extensões ou parâmetros que o serviço gerenciado não libera?
- O orçamento mensal tem folga para pagar o preço da comodidade?
- Os dados exigem uma localização ou um controle contratual específico?
Se a resposta para a primeira pergunta é "não" e a segunda pergunta tem um número alto, o serviço gerenciado costuma ser o caminho mais tranquilo. Se há uma pessoa disposta a assumir a operação, a carga é previsível e o orçamento é curto, PostgreSQL em VPS entrega mais desempenho e mais liberdade por real gasto. Para pequenas equipes que ficam no meio do caminho, a abordagem mista funciona bem: servidor virtual para estudar e testar, serviço gerenciado para o que não pode falhar.
Seja qual for a escolha, três hábitos valem nos dois modelos: backups guardados fora da máquina do banco, restauração testada com regularidade e monitoramento com alertas. Quer aprofundar a prática de administração de servidores? O blog da Serverspace reúne outros materiais sobre infraestrutura e Linux.
Perguntas frequentes
Um VPS é seguro o suficiente para guardar dados de clientes?
Sim, desde que a configuração seja cuidadosa: firewall restrito, acesso ao PostgreSQL limitado a IPs conhecidos, TLS ativo, senhas fortes, atualizações em dia e cópias de segurança fora do servidor. A segurança depende mais da disciplina da equipe do que do tipo de hospedagem.
É possível começar no VPS e migrar depois para um serviço gerenciado?
É possível e bastante comum. Como o PostgreSQL é o mesmo, a migração costuma ser feita com pg_dump e pg_restore ou com replicação lógica, quando o tempo de parada precisa ser mínimo. O ponto de atenção é conferir antes se as extensões usadas existem no serviço de destino.
O serviço gerenciado elimina a necessidade de fazer backup por conta própria?
Elimina o trabalho de montar e agendar as cópias, mas não o de verificá-las. Confira o período de retenção, teste a restauração e, para dados críticos, considere guardar um dump adicional em outro local. Assim o backup do PostgreSQL não depende de um único provedor.
Qual configuração de VPS serve para começar?
Para aplicações pequenas e médias, 2 vCPU, entre 4 e 8 GB de RAM e disco NVMe formam um ponto de partida razoável. Acompanhe o uso real de memória, disco e conexões durante as primeiras semanas e aumente os recursos quando as métricas pedirem.
Preciso de réplica desde o primeiro dia?
Depende do impacto de uma parada. Em projetos em fase inicial, backups frequentes e um procedimento de restauração ensaiado costumam bastar. Quando a indisponibilidade custa caro, a réplica com failover entra no planejamento desde o começo.
Quando faz sentido ter um DBA dedicado?
Em geral, quando o banco passa de algumas centenas de gigabytes, a carga exige ajuste constante ou a equipe gasta com regularidade mais tempo no banco do que no produto. Antes desse ponto, um profissional de infraestrutura com bons conhecimentos de PostgreSQL costuma dar conta.