> ## Documentation Index
> Fetch the complete documentation index at: https://docs.replit.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Como o Publish atualiza seu banco de dados de produção

> Saiba como o Replit compara, valida e aplica à produção as alterações de esquema do seu banco de dados de desenvolvimento quando você publica seu app.

Quando você publica um app que usa um banco de dados gerenciado pelo Replit, o Replit atualiza seu banco de dados de produção para corresponder ao seu banco de dados de desenvolvimento, por você. Você não escreve nem executa migrações por conta própria. Durante a publicação, o Replit:

1. Compara o esquema dos seus bancos de dados de desenvolvimento e produção.
2. Gera o SQL necessário para fazer a produção corresponder ao desenvolvimento.
3. Pede que você resolva qualquer ambiguidade, como uma coluna renomeada.
4. Valida o SQL em uma cópia do seu banco de dados de produção.
5. Aplica o SQL à produção depois que seu app é compilado e antes de a nova versão entrar no ar.

> [!NOTE]
>
> Isso só se aplica a bancos de dados que o Replit gerencia para o seu app. Se seu app publicado se conecta a um banco de dados externo, como Supabase, um projeto do Neon que você mesmo criou ou o Amazon RDS, o Publish não altera esse banco de dados. Use o fluxo de migração desse provedor.

## Etapa 1: o Replit detecta as alterações

A publicação começa com uma etapa de **Provision**. Se o esquema de desenvolvimento for diferente do de produção, o painel Publish mostra **Development database changes detected** e começa a gerar as migrações.

![Painel Publish mostrando Development database changes detected](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/changes-detected.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=9213aa45a2b15109f3cffc451fb7efdf)

A publicação migra tabelas, colunas, índices, restrições, views, enums, sequências e políticas de segurança em nível de linha. Alguns objetos não são transferidos; veja [Objetos de banco de dados não compatíveis](https://docs.replit.com/pt/help/troubleshooting/databases.md#objetos-de-banco-de-dados-não-compatíveis).

## Etapa 2: responda perguntas sobre alterações ambíguas

Algumas alterações de esquema podem ter dois significados. Quando o Replit não consegue saber qual você pretendia, ele pausa com **Detected potential conflicts, please review** e pede que você escolha. Selecione uma opção e depois **Submit**.

### Renomear ou nova?

Se uma coluna foi removida e outra adicionada na mesma tabela, o Replit pergunta se a coluna antiga foi renomeada.

* **Yes, rename column** mantém os dados existentes sob o novo nome.
* **No, create new column** adiciona uma coluna vazia e descarta a antiga junto com seus dados.

![Pergunta sobre se uma coluna removida deve ser renomeada para uma coluna recém-adicionada](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/rename-column-prompt.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=fe35615b66e1cc80a57b0198926d5406)

A mesma pergunta aparece para tabelas, enums, sequências, views e esquemas.

![Pergunta sobre se uma tabela removida deve ser renomeada para uma tabela recém-adicionada](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/rename-table-prompt.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=f3bfb9ba5604a051e845ae3617e42270)

> [!WARNING]
>
> Escolher **create new** para algo que na verdade era uma renomeação é a forma mais comum de perder dados de produção durante uma publicação. Se você não tiver certeza, cancele a publicação e pergunte ao Agent o que mudou.

### Restrição de unicidade em uma tabela com dados

Se você adicionar uma restrição de unicidade a uma tabela que já tem linhas em produção, o Replit informa quantas linhas a restrição vai verificar.

* **Add the constraint as-is** faz a migração falhar se alguma linha existente a violar. Você pode então corrigir os dados e publicar novamente.
* **Remove all rows, then add the constraint** limpa a tabela primeiro. Essa opção não é oferecida quando outras tabelas referenciam esta por meio de uma chave estrangeira.

![Pergunta sobre como adicionar uma restrição de unicidade a uma tabela que já tem linhas](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/unique-constraint-prompt.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=0a399148516559f9f2711cc335254df2)

## Etapa 3: revise o SQL gerado

Depois que as perguntas são respondidas, o painel mostra **Generated migrations to apply to production database** com o SQL exato que o Replit vai executar. Leia-o antes de continuar.

![SQL de migração gerado exibido no painel Publish](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/generated-migrations.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=d8737c76546c059cdfcf0adead1e9e29)

Dois sinais indicam que uma migração precisa de atenção extra:

* **Aviso de perda de dados.** Quando uma alteração pode remover dados de uma tabela que tem linhas em produção, o painel fica laranja e lista cada tabela afetada com sua contagem de linhas. As alterações que acionam esse aviso incluem:
  * Remover ou recriar uma coluna ou tabela
  * Alterar o tipo de uma coluna ou se ela exige um valor
  * Adicionar uma coluna obrigatória
  * Adicionar ou recriar índices e restrições
* **Aviso de inatividade.** Quando uma alteração não é compatível com a versão do seu app que está em execução, o Replit para o app em execução antes de aplicar a migração, para que os usuários não possam gravar no banco de dados durante a alteração. Expanda **What's happening?** para ver detalhes.

![Migração com um aviso laranja de perda de dados listando as tabelas afetadas e um aviso de inatividade](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/data-loss-warning.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=fc53902e5f2c4db51429cfc04f0e2746)

> [!NOTE]
>
> A lista de avisos inclui apenas tabelas que contêm linhas em produção. Um `DROP TABLE` em uma tabela vazia não mostra aviso, então leia o SQL mesmo quando o painel não estiver laranja.

## Etapa 4: o Replit valida a migração

O Replit cria uma cópia temporária do seu banco de dados de produção e executa o SQL nela. O painel mostra **Validating database migrations...** e depois **Database migrations validated successfully**.

![Painel Publish mostrando que as migrações do banco de dados foram validadas com sucesso](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/validated.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=7127c8d7f2e63d87be279b5a0fff4e69)

Se o SQL falhar na cópia, o painel mostra **Migrations failed validation, please review** com o erro do banco de dados e três caminhos a seguir:

| Opção | O que ela faz |
| - | - |
| **Ask Agent to investigate and fix the development schema** | O Agent lê o SQL com falha e o erro, compara seu esquema de desenvolvimento com uma visão somente leitura da produção e corrige o lado do desenvolvimento. A produção não é alterada. Publique novamente quando terminar. |
| **Cancel deployment and retry once your schema conflicts are resolved** | Interrompe a publicação. Nada muda na produção. |
| **Copy your development database schema & data to production** | Substitui o esquema **e os dados** da produção pelos do desenvolvimento. Isso só pode ser desfeito com a [recuperação de dados](https://docs.replit.com/pt/features/data-and-storage/data-recovery.md). Use somente em apps sem dados de produção que valha a pena manter. |

![Painel Publish mostrando que as migrações falharam na validação, com três opções de resolução](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/validation-failed.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=0ece6685e16081c9d3525121441ee5a0)

> [!NOTE]
>
> Apps que usam um banco de dados [Databricks Lakebase](https://docs.replit.com/pt/connectors/warehouses/databricks.md) pulam esta etapa de validação. O painel pede que você revise o SQL gerado por conta própria antes de aprovar.

![Painel Publish informando que a validação por prévia não está disponível para o Lakebase](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/lakebase-skipped.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=b6ad241f4884be8f6d085d53511e7beb)

## Etapa 5 (opcional): visualize seu app na cópia migrada

Depois que a validação for bem-sucedida, você pode selecionar **Create preview deploy** para compilar seu app com base na cópia migrada da produção. Quando a compilação terminar, selecione **View preview** para abri-la.

![Painel Publish enquanto uma implantação de prévia está sendo compilada](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/preview-building.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=18d331eba4d12dd001b6084d20481bac)

![Painel Publish com os botões View preview e Approve and publish](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/preview-ready.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=1ed89987ab33ff747694a9460681cc4a)

Use a prévia para navegar pelas partes do seu app que a alteração de esquema afeta. A prévia usa os dados copiados, então nada do que você fizer ali afeta a produção. As prévias expiram **2 horas** após serem criadas; crie uma nova se precisar de mais tempo.

## Etapa 6: aprove e publique

Selecione **Approve and publish** para continuar. O Replit envia o SQL exato que você revisou junto com a solicitação de publicação, então o que você viu é o que será executado.

A publicação então segue pelas etapas restantes. A migração é executada **depois que a compilação do seu app termina e antes de a nova versão ser promovida**:

1. Verificações de segurança
2. Compilação
3. Migração do banco de dados aplicada à produção
4. Empacotamento e promoção da nova versão

Como o Replit aplica a migração neste ponto, o comando de compilação e o código de inicialização do seu app nunca devem alterar o esquema do banco de dados. Não adicione `drizzle-kit push`, `db:push` nem instruções `CREATE TABLE IF NOT EXISTS` ao comando de compilação da implantação ou ao ponto de entrada do seu servidor. Eles seriam executados a cada publicação, fora da revisão e da validação acima.

> [!WARNING]
>
> Depois que você aprova, a migração não pode ser revogada pelo painel Publish. Se precisar desfazer uma alteração de esquema após a publicação, faça a alteração inversa no desenvolvimento e publique novamente, ou use a [recuperação de dados](https://docs.replit.com/pt/features/data-and-storage/data-recovery.md).

Se você pedir ao Agent para republicar em vez de usar o painel Publish e seus esquemas de desenvolvimento e produção forem diferentes, a republicação é bloqueada e você é direcionado de volta ao painel Publish para revisar a migração.

## Faça alterações manuais na produção

Para correções pontuais, você pode executar SQL diretamente na produção a partir do painel Database: selecione **Production** no seletor de bancos de dados e use o console SQL. Veja [Trabalhe com seus dados](https://docs.replit.com/pt/features/data-and-storage/work-with-your-data.md#executar-comandos-sql).

O Replit sempre compara os bancos de dados reais, não o seu arquivo de esquema, então qualquer alteração manual passa a fazer parte da comparação da próxima publicação. Se você adicionar manualmente em produção uma coluna que não existe no desenvolvimento, a próxima publicação propõe descartá-la.

## Próximos passos

* [Bancos de dados de desenvolvimento e produção](https://docs.replit.com/pt/features/data-and-storage/development-and-production.md): Entenda como seus dois bancos de dados diferem.
* [Recuperação de dados](https://docs.replit.com/pt/features/data-and-storage/data-recovery.md): Restaure dados de desenvolvimento ou produção.
* [Objetos de banco de dados não compatíveis](https://docs.replit.com/pt/help/troubleshooting/databases.md#objetos-de-banco-de-dados-não-compatíveis): Objetos que o Publish não consegue migrar.