PostgreSQL gerenciado no Dockup: guia completo

O PostgreSQL gerenciado fornece à aplicação um banco de dados provisionado, com operações de ciclo de vida independentes do container do serviço. O Dockup oferece criação, inicialização e parada, logs, inspeção de tamanho, backups, restauração pela plataforma, usuários somente leitura, migração entre nodes e networking privado.

O princípio operacional fundamental é a separação: a imagem da aplicação é descartável, os dados do PostgreSQL são duráveis, as credenciais são secrets e a recuperação do banco de dados deve ser testada de forma independente do rollback da aplicação.

Como criar um banco de dados PostgreSQL gerenciado?

Selecione o workspace desejado e crie o banco de dados:

dockup db create \
  --name main-db \
  --type postgresql \
  --json

Liste os bancos de dados para confirmar o slug e o status exatos:

dockup db list --json

As operações de banco de dados usam destinos no formato project/db:

dockup db size production/main-db --json

Aguarde a conclusão do provisionamento antes de conectar uma aplicação. Não tente deduzir o hostname, a porta, o nome de usuário ou a senha a partir do nome do banco de dados.

O plano Free permite três bancos de dados em um workspace e inclui um crédito inicial de US$ 10. Os planos pagos — Hobby por US$ 5, Pro por US$ 20 por mês — permitem bancos de dados, workspaces e deployments ilimitados. O consumo de CPU, RAM e disco é medido por minuto, descontando-se do saldo de uso incluído.

Como conectar uma aplicação com segurança?

Obtenha os dados de conexão do banco de dados na interface de banco de dados do Dockup e trate a connection string como um secret. Não a cole no repositório nem no transcript do agent.

Defina-a no serviço:

dockup env set DATABASE_URL="$DATABASE_URL" \
  --secret \
  -s production/api \
  --json

dockup deploy production/api --wait --json

O redeploy é necessário porque o processo em execução recebeu seu ambiente durante a inicialização. O valor armazenado aparece mascarado quando a configuração do ambiente é lida.

Configure o connection pooling da aplicação de forma deliberada. Muitos workers da aplicação com pools grandes podem esgotar as conexões do banco de dados mesmo quando a CPU e a memória parecem saudáveis. Defina o tamanho do pool com base na carga de trabalho e na capacidade do banco de dados, não no número máximo aceito por um framework.

Teste uma nova conexão após o deployment. Um endpoint de health pode confirmar que o processo HTTP está ativo sem comprovar que uma nova sessão no banco de dados pode ser estabelecida.

O guia sobre variáveis de ambiente e secrets aborda a rotação de credenciais e a exibição mascarada.

Como o networking privado protege o tráfego do PostgreSQL?

Ative uma rede privada do projeto:

dockup network enable production --json

Os serviços e bancos de dados gerenciados nesse projeto recebem hostnames estáveis no formato <slug>.internal. Faça o redeploy da aplicação para receber as variáveis de conexão internas injetadas.

Para remover o listener público do banco de dados e torná-lo acessível apenas de forma privada:

dockup db private production/main-db --json

Restaure o acesso público e privado quando necessário:

dockup db private production/main-db --off --json

Tornar o banco de dados acessível apenas de forma privada recria o container, preservando os dados. Agende e verifique essa alteração como uma operação de banco de dados, não como uma simples edição de DNS.

O networking privado controla a rota, enquanto as credenciais do PostgreSQL controlam a identidade e a autorização. Mantenha ambos. Projetos separados não conseguem acessar uns aos outros porque cada projeto tem sua própria rede.

O artigo sobre networking privado e domínios internos apresenta a topologia completa.

Como funcionam o backup e a restauração do PostgreSQL?

Liste os backups existentes:

dockup db backups production/main-db --json

Inicie um backup no servidor:

dockup db backup production/main-db --json

O comando de backup cria um backup ciente do banco de dados, em vez de uma cópia a quente do volume bruto. Registre o ID do backup, o horário de criação, a versão do banco de dados e o motivo.

O Dockup permite restaurar backups de bancos de dados gerenciados pela plataforma. A referência atual da CLI não documenta um comando dockup db restore, portanto este guia não inventa um. Faça a restauração pela interface compatível do Dockup, selecione o backup exato, obtenha a aprovação para produção e verifique o resultado.

Um plano de restauração deve incluir:

1. Ponto de recuperação e janela esperada de perda de gravações.
2. Congelamento das gravações da aplicação ou comportamento durante a manutenção.
3. Compatibilidade do banco de dados e das extensions.
4. Novo backup do estado atual, quando for útil.
5. Responsável pela restauração e aprovação.
6. Reconexão da aplicação e smoke test.
7. Registro de auditoria e do incidente.

Os backups não são comprovados até que um restore drill seja concluído com sucesso. Use um banco de dados que não seja de produção ou um ambiente de recuperação aprovado para testar o procedimento.

Mantenha os backups de acordo com uma política aprovada. Remova pontos de recuperação obsoletos somente pela interface de banco de dados compatível, depois de verificar que nenhum requisito de recuperação ou compliance ainda depende deles.

Como funcionam os usuários PostgreSQL somente leitura?

Usuários adicionais somente leitura são úteis para analytics, investigações de suporte, deployments de preview e ferramentas que precisam consultar sem gravar.

Liste os usuários:

dockup db users production/main-db --json

Crie um usuário com um label:

dockup db user-add production/main-db \
  --label analytics \
  --json

Capture a credencial gerada com segurança durante a criação e não a reproduza em uma resposta do agent. Revogue o usuário adicional pela interface compatível de gerenciamento de usuários do banco de dados quando sua finalidade terminar.

O acesso somente leitura na camada de permissões do banco de dados é mais forte do que dizer a uma ferramenta de consulta “não grave”. Ainda assim, ele permite acesso aos dados de produção que podem ser lidos; portanto, aplicam-se as regras de privacidade e least privilege.

O Dockup cria automaticamente um usuário de banco de dados somente leitura para um PR ou branch preview em um projeto com networking privado. O preview pode acessar o mesmo banco de dados de produção em <slug>.internal e ler dados sem obter permissão de gravação.

Como monitorar tamanho, logs e posicionamento?

Inspecione o tamanho em disco:

dockup db size production/main-db --json

Analise os logs de runtime da aplicação em busca de falhas de conexão, sem expor senhas ou connection strings completas:

dockup logs production/api --json

A manutenção do banco de dados pode deixar os serviços dependentes indisponíveis. Agende operações que alteram o estado, exija aprovação operacional explícita e comunique o impacto antes de agir.

Mova um banco de dados entre nodes usando um ID de node de destino:

dockup db migrate production/main-db \
  --node <nodeId> \
  --json

A migração é uma operação stateful. Confirme o status do backup, as expectativas de manutenção, as conexões de networking privado e as verificações da aplicação após a movimentação.

Checklist de produção do PostgreSQL gerenciado

Um runbook completo registra:

Área	Evidência necessária
Identidade	Destino project/db exato
Conectividade	Connection string secreta e nova sessão testada
Rede	Política pública, privada ou somente privada
Acesso	Role da aplicação e usuários somente leitura identificados por label
Capacidade	Tamanho atual e análise de crescimento
Backups	IDs de backups recentes e retenção
Recuperação	Restore drill concluído com sucesso
Operações	Aprovação para inicialização, parada, reinicialização e migração
Auditoria	Alterações no banco de dados rastreáveis a um ator

O rollback do deployment da aplicação não restaura o PostgreSQL. A restauração do banco de dados não reverte automaticamente o código da aplicação. Coordene ambos somente quando a compatibilidade do schema exigir.

Para decisões mais amplas de scaling, leia estratégias de scaling de bancos de dados. Para comandos exatos, use a referência da CLI do Dockup.

Projete as migrations de schema para deployment e rollback

O deployment da aplicação e a alteração do schema do banco de dados acontecem em timelines diferentes. Uma migration segura geralmente é backward compatible por pelo menos uma janela de release: adicione uma coluna nullable antes de torná-la obrigatória, faça o deployment de um código que consiga lidar com ambos os schemas, execute o backfill de forma controlada e remova a estrutura antiga posteriormente.

Não faça um health check executar uma migration longa. Se a aplicação iniciar várias réplicas, garanta que apenas um migration runner possa assumir a alteração. O comando exec do container PRO pode executar um comando único e propagar seu exit code real:

dockup exec "npm run migrate" \
  -s production/api \
  --json

Use-o somente quando o comando de migration tiver sido revisado e o serviço estiver em execução no servidor principal compatível. Capture stdout, stderr e o exit code. Um deployment bem-sucedido da aplicação não significa que uma migration com falha possa ser ignorada.

Faça a rotação das credenciais do banco de dados sem indisponibilidade

Crie a nova credencial ou o usuário somente leitura, atualize o secret do serviço consumidor, faça o redeploy e verifique uma nova conexão antes de revogar a credencial antiga. Os connection pools existentes podem ocultar uma nova senha incorreta até que se reconectem.

Para a credencial principal da aplicação, use a interface compatível do Dockup e a política do banco de dados. Para um usuário analítico adicional, crie uma conta somente leitura identificada por label e distribua-a apenas ao consumidor aprovado.

O registro da rotação deve listar o label do usuário, os serviços consumidores, os IDs de deployment, a query de verificação, o horário da revogação e o evento de auditoria — nunca a senha.

Observe o crescimento antes de fazer scaling

O tamanho do banco de dados é um dos sinais:

dockup db size production/main-db --json

Combine-o com a latência das queries da aplicação, a contagem de conexões, o comportamento do cache, a duração dos backups e o crescimento do storage. Uma alocação maior de CPU ou memória pode não corrigir a ausência de indexes ou queries sem limite.

Consulte estratégias de scaling de bancos de dados antes de mover nodes ou aumentar recursos. O PostgreSQL gerenciado reduz o trabalho de provisionamento, mas o design do schema e das queries continua sendo responsabilidade da aplicação.

Separe disponibilidade de correção

Um container de banco de dados em execução comprova que o PostgreSQL está disponível, não que as queries da aplicação estão corretas. Inclua uma nova conexão de baixo risco e uma leitura representativa na verificação pós-deployment. Para um teste de gravação, use uma transaction dedicada ou um registro de teste que possa ser removido com segurança.

O runbook de PostgreSQL gerenciado também deve informar se réplicas, usuários de analytics, previews ou workers em segundo plano criam pressão adicional sobre as conexões.

Revise regularmente o acesso ao PostgreSQL

Liste os usuários adicionais, confirme que cada label tem um owner ativo e remova as contas obsoletas. Essa revisão simples impede que o acesso de leitura do PostgreSQL gerenciado se acumule após o fim de previews, projetos de analytics ou investigações de suporte.

Comece com um deployment verificável

Crie um banco de dados PostgreSQL que não seja de produção, conecte um serviço de teste por meio de um secret mascarado, faça um backup e conclua um restore drill antes do cutover para produção.

Comece gratuitamente em app.dockup.ai. O plano Free custa US$ 0 por mês, inclui um crédito inicial de US$ 10 e oferece suporte a um workspace, três bancos de dados e três deployments.

FAQ

Quais tipos de bancos de dados gerenciados o Dockup oferece?

O Dockup oferece bancos de dados gerenciados PostgreSQL, MySQL, MongoDB e Redis.

Como uma aplicação deve receber sua connection string do PostgreSQL?

Trate a connection string como uma variável de ambiente secret, defina-a no serviço exato e faça o redeploy para que o novo container a receba.

O Dockup pode criar um usuário PostgreSQL somente leitura?

Sim. O comando database user-add cria um usuário adicional somente leitura e retorna a senha uma única vez, durante a criação.

Existe um comando documentado dockup db restore na CLI?

A referência atual da CLI não documenta esse comando. O Dockup oferece suporte à restauração de backups pela interface da plataforma; portanto, use esse caminho compatível em vez de inventar uma flag ou um comando.

O rollback da aplicação restaura o banco de dados PostgreSQL?

Não. O histórico de deployments da aplicação e o histórico de backups do banco de dados são sistemas de recuperação separados e precisam ser coordenados quando as alterações de schema exigem ambos.