PostgreSQL e Redis em VPS: quando sair do gerenciado em 2026?

Sair de PostgreSQL ou Redis gerenciado para uma VPS faz sentido quando controle, compatibilidade ou custo previsível compensam uma rotina real de operação. Sem backup externo, restore testado e alguém responsável por incidentes, a economia é aparente. Uma VPS pode simplificar a conta inicial, mas não transforma uma única máquina em alta disponibilidade.

Para Rafael, o solo builder que mantém um micro-SaaS, agentes de IA ou uma automação interna, a decisão parece simples no começo: banco gerenciado custa mais; uma VPS comporta app, PostgreSQL e Redis. O problema começa quando a pergunta deixa de ser “funciona hoje?” e passa a ser “quem recupera o serviço quando a VM, o volume ou a atualização falhar?”.

Este é um comparativo de condição, não de torcida. PostgreSQL e Redis podem rodar em Docker numa VPS. Isso não prova que devam rodar lá. A escolha depende do papel de cada dado, do prejuízo aceitável numa indisponibilidade e da rotina que alguém consegue manter.

A pergunta não é “cabe na VPS?”, é “quem recupera quando ela cai?”

O conceito que guia esta decisão é o Custo de Recuperação. Ele não é o preço do servidor. É o conjunto de trabalho e recursos necessários para restaurar a operação no prazo que o negócio aceita quando algo quebra.

A documentação do PostgreSQL separa backup em dump SQL, backup no nível de sistema de arquivos e arquivamento contínuo para recuperação em ponto no tempo. O projeto também usa WAL, mantido em pg_wal, para recuperar consistência após crash e apoiar esse arquivamento contínuo. Essas opções existem; escolher uma não substitui testar a volta do serviço. Veja os métodos oficiais de backup do PostgreSQL e a explicação de WAL e recuperação em ponto no tempo.

A leitura do Runzos é objetiva: um backup que nunca foi restaurado é uma hipótese, não uma capacidade operacional. Snapshot local, volume anexado e cópia no mesmo host podem ajudar em incidentes específicos. Mas não resolvem a perda daquele mesmo domínio de falha.

RPO é o ponto máximo de perda de dados aceitável. RTO é o tempo máximo aceitável para voltar. Não há um número universal para ambos. Eles vêm do negócio, do tipo de dado e da consequência de ficar indisponível.

PostgreSQL e Redis fazem trabalhos diferentes — e toleram perdas diferentes

Tratar PostgreSQL e Redis como “dois bancos” conduz a escolhas ruins. PostgreSQL costuma concentrar dados transacionais e persistentes da aplicação. Redis é um datastore em memória e pode servir como cache, sessão, fila ou estruturas de dados. O impacto de perder cada item depende do uso que a aplicação deu a ele.

PostgreSQL: fonte de verdade exige caminho de recuperação

Se pedidos, usuários, configurações ou registros de trabalho dependem do PostgreSQL, o banco tende a ser a fonte de verdade da aplicação. pg_dump com formato de arquivo e pg_restore permitem backup lógico e restauração seletiva. A documentação também diferencia essa rota de um backup de filesystem para migrações entre versões principais.

Na prática, não basta agendar um dump. Defina onde ele sai da VPS, como as credenciais ficam protegidas, onde será restaurado e como confirmar que os dados voltaram utilizáveis. O teste deve acontecer em ambiente isolado, sem apontar a aplicação para uma cópia que você está validando.

Redis: cache, sessão e fila não têm a mesma política

Redis oferece snapshots RDB em intervalos, AOF com registro das escritas e a opção de não usar persistência. A escolha deve seguir a função do dado. Cache que pode ser recalculado tolera uma política diferente de uma fila cujo desaparecimento interrompe um processo de negócio.

A replicação padrão do Redis é assíncrona. Portanto, replicar não autoriza prometer perda zero durante failover. ACL também pode limitar comandos e chaves acessáveis, o que ajuda a reduzir o escopo de uma credencial comprometida. A configuração precisa ser avaliada no workload real.

Arquitetura mínima em Docker sem expor o banco na internet

Docker Compose descreve serviços, redes e volumes. Ele não entrega, sozinho, backup, monitoração ou alta disponibilidade. Uma arquitetura inicial razoável mantém o app acessível pelo caminho público necessário e PostgreSQL/Redis numa rede Docker privada. O banco e o cache não precisam receber tráfego direto da internet para conversar com o app.

No PostgreSQL, o padrão de listen_addresses é localhost, e a porta padrão é 5432. No Redis, a orientação oficial para uma VM exposta inclui usar firewall para impedir acesso externo e fazer bind em loopback; a documentação alerta que expor a porta pode ter impacto grave. Leia a orientação oficial de segurança de rede do Redis antes de liberar qualquer acesso administrativo.

Para administração, prefira rede privada, VPN, túnel controlado e regras de firewall. Expor 5432 ou 6379 “só para facilitar” transforma uma escolha de conveniência em superfície de ataque. Senha não substitui isolamento de rede.

Também vale separar segredo de configuração comum. Docker Compose tem mecanismo de secrets para itens como senha, certificado e chave de API. Isso não elimina permissões, rotação ou backup seguro, mas evita tratar uma credencial como texto qualquer no repositório.

Quando a VPS faz sentido

A VPS faz sentido quando existe uma razão específica para assumir controle e você consegue aceitar a rotina associada. Alguns cenários são coerentes:

• Você precisa de configuração, extensão ou versão que o banco gerenciado não atende.
• O app tem carga e risco conhecidos, com dados recuperáveis e plano de restauração validado.
• Há alguém responsável por atualização, alerta, capacidade e incidente.
• O backup sai da VM e o restore foi registrado em ambiente isolado.
• O custo previsível da infraestrutura ajuda o negócio sem esconder o tempo de operação.

Isso não é um convite para condensar tudo em um único host por reflexo. App, Postgres, Redis e a única cópia do backup na mesma VPS formam um único domínio de falha. A montagem pode ser aceitável no início, desde que seja chamada pelo nome: uma arquitetura simples, não redundância.

Se sua prioridade é colocar uma stack Docker sob controle e você já tem o plano operacional, vale ver uma VPS para rodar sua stack Docker. A oferta é uma rota interna do Runzos. Ela não substitui a validação de requisitos, backup e suporte necessário para sua aplicação.

Quando o banco gerenciado é a escolha mais barata na prática

A fatura do serviço gerenciado pode ser maior. Mesmo assim, ele pode custar menos quando evita uma indisponibilidade que ninguém sabe diagnosticar ou recuperar. Isso vale especialmente para o primeiro banco de produção, para dado crítico sem operador definido e para requisitos de disponibilidade que uma VM única não demonstra cumprir.

O custo oculto da VPS não é defeito da VPS. É a Dívida de Operação que ela transfere para o time: atualizar imagem, revisar segredos, acompanhar disco e memória, responder a alertas, manter cópias externas e executar restore. Nesta pauta, porém, o Custo de Recuperação vem primeiro: você só sabe se assumiu essa dívida quando consegue recuperar o serviço de verdade.

Há ainda a portabilidade. PostgreSQL usa SQL e protocolo conhecidos, mas uma migração depende de extensões, versões, permissões, volume de dados e dependências da aplicação. Por isso, “sem lock-in” não é promessa séria. Para aprofundar esse ponto, veja o post do Runzos sobre Postgres-first e lock-in.

A tabela não preenche preços porque eles variam por plano e data. A comparação honesta começa listando o que está dentro e fora da fatura, não inventando um total mensal.

Redis, Valkey e a licença que não cabe no benchmark

Redis Open Source apresenta, a partir do Redis 8, opções RSALv2, SSPLv1 e AGPLv3. Valkey se apresenta como datastore open source sob licença BSD, apoiado pela Linux Foundation, e mantém imagens Docker próprias. Isso cria uma decisão de licença e compatibilidade, não um vencedor automático.

A persistência do Redis continua sendo uma decisão de arquitetura, independentemente do nome escolhido. RDB, AOF ou nenhum estado precisam acompanhar a função do dado. Para detalhes, consulte a documentação de persistência RDB e AOF do Redis.

Valkey pode ser uma alternativa para casos em que licença e ecossistema pesam. Não trate isso como substituição universal. Teste imagem, comandos, módulos, cliente e comportamento da sua aplicação antes de migrar qualquer carga.

Checklist final: só auto-hospede se marcar todos os itens

1. Definir RPO e RTO com base no impacto real para o negócio.
2. Identificar se Postgres, Redis ou ambos guardam dados que não podem sumir.
3. Manter PostgreSQL e Redis sem portas públicas expostas.
4. Separar app público de banco e cache por rede privada.
5. Guardar segredos com controles adequados e prever rotação.
6. Levar backup para fora da VPS que roda a aplicação.
7. Restaurar PostgreSQL em ambiente isolado e registrar o resultado.
8. Testar a recuperação Redis conforme RDB, AOF ou a ausência planejada de persistência.
9. Monitorar disco, memória, conexões e execução das cópias.
10. Planejar atualização de imagem, versão e extensão antes do incidente.
11. Validar a compatibilidade da aplicação antes de escolher Redis ou Valkey.
12. Manter um responsável claro pelo incidente e pelo restore.

Se algum item ainda é uma promessa futura, o banco gerenciado provavelmente continua sendo a opção mais prudente. Não por falta de capacidade técnica, mas porque a operação ainda não tem uma recuperação verificável.

FAQ — Perguntas frequentes sobre PostgreSQL e Redis em VPS

PostgreSQL em Docker é seguro para produção?

Docker não torna PostgreSQL seguro ou inseguro por si só. A segurança depende de rede, autenticação, segredos, atualização e operação. Docker Compose pode organizar serviços, volumes e rede, mas não entrega backup, monitoração nem alta disponibilidade sozinho. Para produção, valide sobretudo a exposição de rede, a cópia externa e a restauração antes de depender da instância.

Redis precisa de backup?

Depende da função do Redis no seu app. Redis pode usar RDB, AOF ou nenhuma persistência. Cache recalculável pode tolerar perda de forma diferente de uma fila ou sessão importante. A decisão deve partir do impacto de perder aquele dado e do comportamento da aplicação ao reiniciar. Se a perda interrompe um processo crítico, configure e teste a recuperação que o caso exige.

Posso expor a porta do Postgres ou Redis?

Não como padrão. PostgreSQL usa 5432 por padrão; Redis deve ser protegido por firewall e acesso externo não é recomendado para uma VM exposta. Use rede privada, VPN, túnel controlado e regras de firewall para administração. Senha, ACL e TLS podem complementar a proteção, mas não substituem o isolamento de rede.

Uma VPS basta para app, Postgres e Redis?

Ela pode bastar como arquitetura inicial para uma carga tolerante, desde que você tenha backup externo e restore testado. Ela não equivale a alta disponibilidade. Quando app, banco, cache e cópia local estão no mesmo host, a indisponibilidade desse host afeta tudo. Para dado crítico ou requisitos rígidos, serviço gerenciado ou arquitetura desenhada para resiliência tende a ser mais prudente.

Quando usar Valkey em vez de Redis?

Considere Valkey quando licença e ecossistema justificarem a avaliação. Valkey se apresenta como BSD e apoiado pela Linux Foundation; Redis Open Source tem opções de licença próprias nas versões atuais. Isso não garante compatibilidade total. Teste comandos, módulos, imagem Docker, biblioteca cliente e comportamento da sua aplicação antes de trocar qualquer serviço de produção.

Conclusão: escolha a VPS depois de aceitar o Custo de Recuperação

PostgreSQL e Redis em VPS podem ser uma boa decisão para quem quer controle e aceita operar a stack. O erro é usar o preço inicial como único critério. A reconciliação prática do Runzos é simples: a documentação mostra ferramentas de backup, persistência e segurança; nenhuma delas transforma uma VPS única em alta disponibilidade sem desenho e teste.

Escolha a VPS quando o ganho de controle ou custo previsível for concreto, o backup estiver fora da máquina e alguém souber recuperar o serviço. Se ainda não existe dono, restore testado ou margem para incidente, manter gerenciado é uma decisão operacional, não uma derrota técnica.

Como alternativa de infraestrutura, você pode comparar uma VPS para Postgres, Redis e seus containers ou avaliar planos de infraestrutura no Runzos. Antes de contratar, confirme recursos, suporte e condições atuais na página de cada oferta.