
Como eles se comparam
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 (adicionar e excluir colunas ou tabelas) são aplicadas ao seu banco de dados de produção.Você pode editar manualmente seus dados de produção: abra a ferramenta Database, selecione o banco de dados de produção, abra My Data e ative Enable Editing.
A publicação usa o drizzle-kit para aplicar alterações em tabelas, colunas, índices, restrições, views e políticas de segurança em nível de linha. Ela não copia domínios, funções, procedimentos, gatilhos (triggers) nem permissões (grants), e tem suporte limitado para roles. Veja Objetos de banco de dados não compatíveis.
Crie um banco de dados de produção ao publicar
Seu app publicado recebe seu próprio banco de dados de produção, separado do banco de dados de desenvolvimento que você usa enquanto constrói.- Infraestrutura atual (Helium): o Replit cria automaticamente um banco de dados de produção quando você publica, desde que seu banco de dados de desenvolvimento contenha dados.
- Bancos de dados de desenvolvimento legados do Neon: você cria o banco de dados de produção a partir das configurações de publicação. Abra Database settings ao publicar, ative Create production database e, opcionalmente, ative Set up your production database with your current development data para copiar seus dados de desenvolvimento.

Primeira publicação: Publishing → Advanced settings → Database settings. Seção de deployment secrets oculta.
Descubra qual banco de dados seu app usa
Em quase todos os casos, seu app publicado usa o banco de dados de produção gerenciado pelo Replit: aquele listado como Production Database na ferramenta Database. Ambos os bancos de dados usam uma variável chamadaDATABASE_URL, mas cada ambiente tem seu próprio valor:
- Project Editor: no seu workspace, no Shell e nas sessões do Agent,
DATABASE_URLaponta para o banco de dados de desenvolvimento. O Replit a conecta automaticamente, então, na infraestrutura atual, ela não aparece em Secrets. - App publicado: quando você publica, seu app recebe um
DATABASE_URLseparado que aponta para o banco de dados de produção.
Ver
REPLIT_ENVIRONMENT=production no Shell não significa que seu workspace usa o banco de dados de produção. Essa variável descreve a plataforma do Replit, não o seu app. Seu app publicado é executado com REPLIT_DEPLOYMENT=1.Peça ao Agent para verificar
O Agent pode verificar seu código e seus Secrets e, para a maioria dos apps, pode consultar seus dados de produção sem alterá-los. O Agent lê a produção por meio de uma réplica de leitura: uma cópia somente leitura do seu banco de dados de produção, mantida atualizada. Alterações muito recentes podem levar um instante para aparecer ali. Uma réplica de leitura não é o mesmo que uma prévia de publicação, que é uma cópia separada e temporária para testar alterações antes de publicar. Cole este prompt no Agent:Prompt
DATABASE_URL, os Secrets não têm nenhuma outra conexão de banco de dados e as linhas mais recentes correspondem ao seu app em produção.
Verifique na ferramenta Database e em Publishing
1
Abra seu banco de dados de produção
Na ferramenta Database, abra o menu de bancos de dados ao lado de All Databases e selecione Production.

2
Encontre um registro do seu app em produção
Abra My Data e procure algo que você criou recentemente no seu app publicado, como uma nova conta ou pedido. Se você conseguir vê-lo, seu app publicado grava neste banco de dados. A produção abre em modo somente leitura, então navegar por ela é seguro.

3
Compare as configurações de conexão
Abra a aba Settings do banco de dados de produção e encontre Connection string. Depois abra Publishing, selecione Adjust settings e encontre 

DATABASE_URL em Production app secrets. Revele cada valor e verifique se ambos apontam para o mesmo host. Para a maioria dos apps, isso significa o mesmo ID de endpoint, a parte que começa com ep-. Um endereço com pooling adiciona -pooler depois do ID, então as strings completas não precisam ser exatamente iguais.

4
Verifique os Secrets em busca de outro banco de dados
Abra Secrets. A conexão integrada do Replit não aparece ali. Se você vir um 
DATABASE_URL que você mesmo adicionou, ou outra conexão de banco de dados, como SUPABASE_DATABASE_URL, seu app pode usar esse banco de dados. Pergunte ao Agent qual deles seu código lê. Um secret NEON_DATABASE_URL é a conexão anterior do seu banco de dados de desenvolvimento, salva durante a atualização da infraestrutura do banco de dados. Seu app só o usa se o seu código o ler.
O que os resultados significam
Essas verificações mostram como seu app está configurado. Se seu app em produção ainda mostrar dados que você não espera, peça ao Agent para encontrar onde seu código lê e grava esses dados.
Pooling de conexões
Por padrão, os bancos de dados de produção não têm pooling de conexões habilitado. Seu app se conecta diretamente ao banco de dados usando a string de conexãoDATABASE_URL, então a maioria dos frameworks deve gerenciar seu próprio pool de conexões no lado do cliente.
Cada projeto do Neon inclui uma string de conexão direta e uma com pooling. Uma string de conexão direta se parece com
postgresql://neondb_owner:<password>@<host>.<region>.neon.tech/<db>?sslmode=require.Para usar a conexão com pooling, adicione -pooler ao host: postgresql://neondb_owner:<password>@<host>-pooler.<region>.neon.tech/<db>?sslmode=require.Fazendo alterações seguras no seu banco de dados de produção
Ao publicar atualizações que incluem alterações de banco de dados, o Replit guia você pela migração no painel Publish. Ele sinaliza alterações que podem remover dados, permite testar seu app em uma cópia migrada da produção e aplica as alterações somente depois que você aprova. Para o fluxo completo, veja Como o Publish atualiza seu banco de dados de produção.Você pode notar um breve tempo de inatividade no seu app publicado durante a publicação. As alterações de banco de dados às vezes exigem parar seu app temporariamente para evitar conflitos e proteger seus dados enquanto as alterações são aplicadas.
- Remover colunas ou tabelas que ainda contêm dados
- Alterar tipos de dados de colunas, o que pode falhar se os valores existentes não forem convertidos
- Adicionar campos obrigatórios sem valores padrão a tabelas que já têm linhas
- Renomear tabelas ou colunas: confirme a renomeação quando o Publish perguntar, ou os dados serão descartados
- Adicionar restrições de unicidade a tabelas cujas linhas existentes possam violá-las
Teste as alterações com uma prévia de publicação
Uma prévia de publicaçã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. Use-a para:- Verificar se seu app ainda funciona com as alterações de banco de dados aplicadas, em todos os seus principais fluxos de usuário
- Confirmar que os dados existentes foram migrados corretamente e que os novos campos contêm os valores esperados
- Observar regressões de desempenho nos tempos de resposta das consultas
Faturamento e uso de recursos
As cobranças do banco de dados de produção incluem uso de computação e armazenamento. O banco de dados entra em estado inativo após cinco minutos de inatividade, pausando a cobrança de computação até que outra consulta chegue. Os dados armazenados continuam gerando cobranças de armazenamento enquanto a computação está inativa. A visão inicial da ferramenta Database mostra seu Billing Period e Hours of Compute Used. Para o armazenamento por banco de dados, abra a aba Settings do banco de dados. Para ver o uso em cada Replit App, acesse Account usage em Settings e expanda as linhas PostgreSQL Storage e PostgreSQL Compute. Para saber como o Replit cobra pelo uso de banco de dados, veja Deployments and Database Billing.Removendo um banco de dados de produção
Recuperar um banco de dados removido é diferente de restaurar linhas ou tabelas excluídas. Para alterações de dados em um banco de dados existente, veja Recuperação de dados.Como remover um banco de dados
Como remover um banco de dados
Na ferramenta Database:
- Selecione o banco de dados, depois abra a aba Settings
- Selecione Remove database e confirme selecionando Yes, Remove database
Banco de dados de desenvolvimento legado
Antes de 4 de dezembro de 2025, o banco de dados de desenvolvimento era hospedado no Neon. Todos os novos bancos de dados de desenvolvimento são hospedados na infraestrutura própria do Replit (Helium). Você pode verificar qual infraestrutura seu app usa na aba Settings: umDATABASE_URL contendo neon.tech significa Neon legado; helium significa a infraestrutura atual.
Atualização da infraestrutura do banco de dados
O Replit está atualizando os bancos de dados de desenvolvimento do Neon para o Helium, a infraestrutura de PostgreSQL própria e gerenciada do Replit. A atualização é automática, é executada uma vez por app quando você abre o app no Project Editor, e preserva todos os seus dados. O que muda:- Menor latência e mais armazenamento: seu banco de dados roda na infraestrutura do Replit junto com seu app, e seu limite de armazenamento aumenta de 10 GB para 20 GB, ou para 50 GB nos planos Pro e Enterprise.
- Mesmo mecanismo de banco de dados: o Helium usa o PostgreSQL 16, a mesma versão do Neon. Suas consultas, esquemas e dados funcionam da mesma forma.
- Conexão atualizada automaticamente:
DATABASE_URLé atualizado para apontar para o Helium. Sua string de conexão anterior do Neon é salva comoNEON_DATABASE_URLnos seus Secrets para referência. - Variáveis PG individuais removidas:
PGHOST,PGPORT,PGUSERePGPASSWORDsão removidas. UseDATABASE_URLem vez disso.
- Strings de conexão do Neon fixas no código: atualize o código que referencia diretamente uma string de conexão
neon.techpara usar a variável de ambienteDATABASE_URLem vez disso. - Funções (roles) personalizadas do PostgreSQL: as funções e permissões são migradas automaticamente, mas as senhas das funções não podem ser copiadas. Redefina as senhas de qualquer função personalizada no novo banco de dados.
Erros de conexão SSL após a atualização
Se você ver erros comoThe server does not support SSL connections, seu código de conexão está forçando um handshake SSL. O Neon exigia SSL; o Helium roda localmente junto com seu app e não o utiliza. Torne a configuração de SSL condicional ao ambiente:
Apps bifurcados que compartilhavam um banco de dados
No sistema legado do Neon, bifurcar um app copiava oDATABASE_URL do app original, então tanto os apps quanto suas versões publicadas se conectavam ao mesmo banco de dados. Os bancos de dados compartilhados legados foram desativados em 8 de junho de 2026. Se o seu app publicado parou de funcionar ou perdeu acesso aos seus dados, veja Fix a published app using a shared database ou contate o suporte.
Próximos passos
- Como o Publish atualiza seu banco de dados de produção: Revise, teste e aprove alterações de esquema ao publicar.
- Recuperação de dados: Restaure dados de desenvolvimento ou produção.
- Detalhes de conexão: Encontre a string de conexão do seu banco de dados.
- Trabalhe com seus dados: Navegue, edite e consulte seus dados.