Migrar um banco existente

O console importa um banco PostgreSQL de qualquer origem a partir da connection string de leitura: o DIVZ testa a conexão, roda o dump e restaura no projeto novo. Bancos de até algumas dezenas de GB migram sem downtime planejado.

Pelo console

1. Crie o projeto de destino, ou escolha um existente.
2. Em Projeto → Migração, cole a connection string de origem — a do banco que você quer trazer, com um usuário que consiga ler tudo.
3. Clique em Testar conexão. O DIVZ confirma que alcança o banco e informa a versão do PostgreSQL de origem antes de mover qualquer byte.
4. Inicie a migração e acompanhe pela tela. O dump e o restore rodam do lado do servidor — você pode fechar o navegador.

Pela API

# 1. testa antes
curl -X POST https://api.divz.com.br/api/v1/migrations/test-connection \
  -H "Authorization: Bearer divz_..." -H "Content-Type: application/json" \
  -d '{"sourceUrl": "postgresql://user:senha@origem.exemplo:5432/banco"}'

# 2. migra
curl -X POST https://api.divz.com.br/api/v1/migrations \
  -H "Authorization: Bearer divz_..." -H "Content-Type: application/json" \
  -d '{"projectId": "<id>", "sourceUrl": "postgresql://..."}'

# 3. acompanha
curl https://api.divz.com.br/api/v1/migrations/<migrationId> \
  -H "Authorization: Bearer divz_..."

De onde dá para migrar

De qualquer PostgreSQL acessível pela internet: Neon, Supabase, Railway, Render, RDS, Cloud SQL, um VPS com Postgres instalado. O que importa é a origem aceitar conexão e o usuário ter permissão de leitura no schema inteiro.

Versões de origem 13 a 18 são suportadas. O destino roda PostgreSQL 16 — migrar de uma versão mais nova para a 16 pode esbarrar em recurso que não existe na 16; nesse caso o erro aparece no restore, com a linha que falhou.

Antes de começar

• Libere o acesso na origem. Se ela tem allowlist de IP, inclua o IP de saída do DIVZ, ou a conexão nem chega a abrir. O suporte informa o endereço.
• Use credencial temporária. Crie um usuário só para a migração e apague depois. Não reaproveite a senha do usuário principal.
• Confira as extensões. Se a origem usa postgis, vector ou similar, instale a extensão no projeto DIVZ antes de migrar. O restore falha ao encontrar um tipo que o banco não conhece.
• Meça o tamanho. SELECT pg_size_pretty(pg_database_size(current_database())) na origem. Dezenas de GB migram tranquilo; centenas merecem uma conversa com o suporte para combinar a janela.

O momento do corte

A migração copia um retrato do banco. O que for escrito na origem depois do dump não vem junto. Para trocar sem perder escrita:

1. Migre uma primeira vez com a aplicação no ar, só para medir quanto tempo leva.
2. Confira o resultado: contagem de linhas por tabela, sequences, índices, extensões.
3. Marque a janela real: coloque a aplicação em modo leitura (ou pare por alguns minutos), rode a migração final e aponte a DATABASE_URL para o DIVZ.
4. Não desligue a origem no mesmo dia. Mantenha por alguns dias, apenas parada — é a rede de segurança mais barata que existe.

Próximo: Segurança e isolamento