> ## 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.
# Bancos de Dados de Produção
> Aprenda como gerenciar e publicar com segurança alterações de banco de dados em ambientes de produção.
Os bancos de dados de produção são dedicados aos seus dados em produção que alimentam seus Replit Apps publicados. Diferente dos bancos de dados de desenvolvimento, onde você experimenta e cria recursos, os bancos de dados de produção mantêm seus dados reais seguros enquanto você continua desenvolvendo, garantindo confiabilidade e desempenho.
Entender como trabalhar com bancos de dados de produção é essencial para criar aplicações robustas que possam evoluir e escalar sem interromper seus usuários.
## O que são bancos de dados de produção?
Os bancos de dados de produção são os bancos de dados operacionais em produção que atendem usuários reais e seus dados. Eles diferem significativamente dos bancos de dados de desenvolvimento em várias formas importantes:
### Produção vs. bancos de dados de desenvolvimento
| Aspecto | Banco de Dados de Desenvolvimento | Banco de Dados de Produção |
| --------------- | ---------------------------------------------------------------- | ----------------------------------------------------------------------------------- |
| **Finalidade** | Experimentação e desenvolvimento de recursos | Atender usuários reais e armazenar dados de negócio |
| **Dados** | Dados de teste, registros fictícios, conjuntos de dados pequenos | Dados reais de usuários, informações críticas para o negócio |
| **Desempenho** | Otimizado para velocidade de desenvolvimento | Otimizado para confiabilidade e experiência do usuário |
| **Alterações** | Alterações frequentes de esquema, iteração rápida | Alterações cuidadosas e planejadas via migrações de dados e estratégias de rollback |
| **Inatividade** | Aceitável durante o desenvolvimento | Deve ser minimizada ou eliminada |
| **Backup** | Opcional para testes | Crítico para a continuidade do negócio |
O Agent não é capaz de modificar o banco de dados de produção; essa restrição existe para manter seu banco de dados de produção seguro.
O Agent pode fazer alterações no seu banco de dados de desenvolvimento. No momento da publicação, quaisquer alterações que você tenha feito com o agent na estrutura do seu banco de dados de desenvolvimento (ou seja, adicionar e excluir colunas/tabelas) serão aplicadas ao seu banco de dados de produção.
Você pode editar manualmente seus dados de produção em qualquer momento acessando o painel de banco de dados > production database > My data e ativando **Edit**
## Tecnologia e infraestrutura do banco de dados
Os bancos de dados de produção no Replit usam as mesmas ferramentas de banco de dados e o mesmo fluxo de publicação da nossa oferta padrão de [SQL Database](/pt/features/data-and-storage/sql-database). Eles executam o PostgreSQL 16 ou 17 hospedado no [Neon](https://neon.tech), oferecendo confiabilidade e desempenho de nível empresarial.
### Relação com o Replit SQL Database
Os bancos de dados de produção se integram à mesma experiência do Replit Database, usando ao mesmo tempo infraestrutura específica para produção:
* **PostgreSQL 16 ou 17**: banco de dados relacional padrão do setor com recursos avançados
* **Infraestrutura Neon**: plataforma de banco de dados serverless que oferece escalonamento automático e otimização de custos
* **Ferramentas integradas**: acesso ao SQL runner, Drizzle Studio e ferramentas visuais de gerenciamento de dados
* **Variáveis de ambiente**: gerenciamento seguro de conexão por meio de credenciais geradas automaticamente
Para informações detalhadas sobre os recursos do banco de dados, configuração de
conexão e especificações técnicas, veja a documentação [SQL
Database](/pt/features/data-and-storage/sql-database).
Os bancos de dados de produção rodam no Neon, enquanto os bancos de dados de desenvolvimento (desde 4 de dezembro de 2025) rodam na infraestrutura própria do Replit. Os dois ambientes diferem nas variáveis de ambiente disponíveis, nos limites de armazenamento e no comportamento de conexão. Veja a seção [Legacy Development Database](/pt/features/data-and-storage/sql-database#legacy-development-database) para detalhes sobre a stack do lado do desenvolvimento.
## Fazendo alterações seguras no seu banco de dados de produção
Ao publicar atualizações no seu Replit App que incluem alterações de banco de dados, você pode encontrar cenários em que um planejamento cuidadoso é essencial para evitar inatividade ou perda de dados.
### Alterações incompatíveis com versões anteriores
Algumas alterações de banco de dados podem quebrar a compatibilidade com o código existente da sua aplicação. Essas alterações exigem tratamento especial para garantir implantações tranquilas.
Você pode notar um breve tempo de inatividade no seu app publicado durante a publicação. Essa inatividade ocorre porque as alterações de banco de dados às vezes exigem parar o app temporariamente para evitar conflitos e garantir atualizações seguras. Parar o app durante essas atualizações ajuda a proteger seus dados contra perda ou corrupção enquanto as alterações são aplicadas.
### Alterações comuns incompatíveis com versões anteriores
Os seguintes tipos de alteração normalmente exigem estratégias de publicação cuidadosas:
* **Remover colunas do banco de dados** que o código da sua aplicação ainda referencia
* **Alterar tipos de dados de colunas** de formas que o código existente não consegue tratar
* **Adicionar campos obrigatórios** sem valores padrão a tabelas existentes
* **Renomear tabelas ou colunas** que quebram consultas existentes
* **Modificar restrições** que possam rejeitar a lógica existente da aplicação
## Prévias de implantação
Antes de publicar alterações de banco de dados em produção, o Replit fornece ferramentas para testar suas alterações com segurança em um ambiente de prévia.
Uma prévia de implantação é uma cópia temporária e isolada do seu ambiente de produção, onde você pode testar alterações de banco de dados e atualizações de aplicação antes que elas afetem usuários reais.
Esse ambiente de prévia espelha sua configuração de produção, mas opera de forma independente.
Ele pode ajudar você a identificar possíveis problemas antecipadamente e garantir que suas alterações funcionem corretamente antes de entrar em produção.
Testar sua implantação no ambiente de prévia é crucial para identificar problemas antes que eles afetem seus usuários. Siga estas etapas para garantir que suas alterações de banco de dados funcionem corretamente:
**1. Testes funcionais**
* Verifique se seu app ainda funciona corretamente com as alterações de banco de dados aplicadas
* Teste todos os principais fluxos de usuário para garantir que a funcionalidade permaneça intacta
* Verifique se os dados são exibidos corretamente após as modificações de esquema
**2. Verificação de integridade dos dados**
* Confirme que os dados existentes foram migrados ou transformados corretamente
* Verifique se os novos campos contêm valores esperados ou padrões apropriados
* Teste casos extremos em que os dados podem não estar em conformidade com as novas restrições
**3. Validação de desempenho**
* Monitore os tempos de resposta das consultas no ambiente de prévia
* Verifique se os novos índices estão sendo usados de forma eficaz
* Verifique se as alterações não introduzem regressões de desempenho
## Restauração para um ponto no tempo
Para bancos de dados de produção, você pode restaurar seu banco de dados para um ponto específico no tempo usando o recurso de restauração para um ponto no tempo.
Até que ponto no passado você pode restaurar depende do seu plano: o plano Core retém até 7 dias de histórico, enquanto os planos Pro e Teams retêm até 28 dias. Se você fizer downgrade do Pro para o Core, sua janela de retenção é reduzida para 7 dias.
Observe que isso apenas restaura seu banco de dados de produção ao estado em que estava no momento do checkpoint. Isso não restaura seu app ao estado em que estava no momento do checkpoint.
Para restaurar seu app ao estado em que estava no momento do checkpoint, você precisará reverter para o checkpoint usando o [recurso de rollback](/pt/features/version-control/checkpoints-and-rollbacks/) e republicar seu app.
## Faturamento e uso de recursos
Os bancos de dados de produção são cobrados com base no uso através do Neon, um provedor de banco de dados serverless.
Os recursos serverless do Neon incluem o seguinte:
* Nenhuma configuração ou manutenção de infraestrutura
* Escalonamento automático para atender às suas necessidades de uso
* Cobrança do tempo de computação apenas quando o banco de dados está ativo
O banco de dados entra em estado inativo após cinco minutos de inatividade, pausando a cobrança do tempo de computação.
Ele é reativado instantaneamente quando recebe uma consulta.
Para saber mais sobre essa tecnologia de banco de dados serverless, veja a documentação
Neon Compute lifecycle.
O Replit fornece acompanhamento em tempo real do uso do seu banco de dados.
Você pode ver o detalhamento do tempo de computação e do uso de armazenamento para o Replit App atual
ou para cada Replit App da sua conta.
Para visualizar o tempo de computação e o uso de armazenamento do seu banco de dados no período de faturamento atual, siga as etapas abaixo:
Na ferramenta **Replit Database**:
1. Navegue até a ferramenta 
**Replit Database** no Project Editor
2. No menu suspenso do banco de dados, selecione **Production**
3. Selecione a aba 
**Settings**
4. A seção **Storage Used** mostra o armazenamento total usado pelo seu banco de dados no período de faturamento atual.
Para visualizar para cada Replit App em **Settings** → **Account** → **Account usage**, siga as etapas abaixo:
1. Abra **Settings** e vá para **Account** → **Account usage** (ou **View account resource limits** / **Usage**).
2. Role até a seção **Resource usage**.
3. Expanda as linhas **PostgresSQL Storage** e **PostgresSQL Compute** para detalhes de cada Replit App.
Para saber como o Replit cobra pelo uso de banco de dados, veja [Deployments and Database Billing](/pt/billing/about-usage-based-billing#databases).
## Solução de problemas comuns
### Falhas de publicação
Se a sua publicação falhar devido a problemas de banco de dados:
1. **Verifique os logs de publicação** para mensagens de erro específicas sobre conectividade do banco de dados ou conflitos de esquema
2. **Verifique as credenciais de conexão do seu banco de dados** para confirmar que estão corretas e acessíveis a partir do ambiente do app publicado
3. **Revise as alterações recentes de esquema** para possíveis conflitos com o código existente da aplicação
4. **Teste suas alterações em um ambiente de prévia** antes de tentar republicar
## Removendo um banco de dados de produção
A ação de remoção é irreversível após um período de retenção de 7 dias. Certifique-se de fazer backup de qualquer dado importante antes de continuar.
Os bancos de dados têm um período de exclusão suave de 7 dias, durante o qual podem ser restaurados. Entre em contato com o suporte se precisar de ajuda. Após 7 dias, o banco de dados é excluído permanentemente e não poderá ser recuperado.
Se você não precisar mais de um banco de dados para o seu Replit App, você pode removê-lo junto com todos os seus dados.
Na ferramenta **Replit Database**:
1. Selecione a aba **Settings**
2. Selecione **Remove database** e confirme selecionando **Yes, Remove database**
## Próximos passos
Para saber mais sobre gerenciamento de banco de dados no Replit:
* [SQL Database](/pt/features/data-and-storage/sql-database): saiba mais sobre o serviço de banco de dados PostgreSQL gerenciado do Replit
* [Deployments](/pt/learn/projects-and-artifacts/replit-deployments): entenda como as implantações funcionam com alterações de banco de dados
* [App Storage](/pt/features/data-and-storage/object-storage): saiba mais sobre como armazenar arquivos e ativos na nuvem (anteriormente chamado de Object Storage)