Migrar do Neon

Os dois produtos entregam PostgreSQL. A diferença está embaixo: o Neon separa armazenamento de computação e ramifica na camada de armazenamento; a CapyDB roda um processo PostgreSQL comum sobre um conjunto de armazenamento dedicado e clona esse conjunto para ramificar. A consequência que você sente é que uma célula da CapyDB se comporta como o Postgres do seu notebook, porque é um.

Seu esquema, suas consultas, suas extensões e suas migrações vão inalterados. O que exige atenção é a camada de conexão e tudo que foi escrito contra um driver específico do provedor.

• -Ramificação: bancos de preview são clones com tempo de vida, um por pull request
• -Escala a zero: uma célula ociosa dorme e acorda na próxima conexão, normalmente em menos de um quarto de segundo
• -Um endpoint via pooler para runtimes serverless e de borda, e um direto para todo o resto
• -Restauração para um ponto no tempo, a partir de arquivamento contínuo em vez de snapshots noturnos
• -Uma integração de plataforma para o destino de deploy em que você já está

• -Sem driver HTTP ou WebSocket: você conecta pelo protocolo nativo do PostgreSQL, que todo driver já fala
• -Isolamento é um processo inteiro e um conjunto de armazenamento por projeto, não um inquilino dentro de uma camada de computação compartilhada
• -Computação é um teto fixo de CPU e memória por plano, não unidades que escalam sozinhas
• -Células padrão não têm acesso de rede para fora, então extensões que chamam serviços externos ficam indisponíveis por construção

Se o seu projeto importa um driver serverless específico do Neon, a CLI o reescreve para você: o codemod troca o cliente por um driver PostgreSQL padrão, corrige a configuração de conexão e sinaliza as chamadas sobre as quais não conseguiu decidir em vez de adivinhar.

# Dry run by default - nothing is written until you say so
capydb migrate codemod neon
capydb migrate codemod neon --write

Inicie uma importação contra sua string de conexão atual. O modo de acompanhamento mantém a nova célula sincronizada com a origem enquanto você testa, então a virada é uma mudança de DNS e variáveis de ambiente em vez de uma janela de manutenção.

capydb import \
  --project my-app \
  --source-url "$OLD_DATABASE_URL" \
  --follow

• -Importe com acompanhamento e deixe rodando enquanto passa sua suíte de testes contra a célula
• -Rode capydb doctor para pegar variáveis de ambiente ainda apontando para o banco antigo
• -Troque a string de conexão na sua plataforma de deploy - a integração faz isso por ambiente
• -Acompanhe os logs e a contagem de conexões no painel nos primeiros minutos
• -Pare o acompanhamento e desative a origem quando estiver satisfeito

Para uma virada em produção, avise antes de começar. Revisamos o plano, ficamos presentes na janela e mantemos um caminho de restauração pronto. Não custa nada e é a diferença entre uma noite entediante e uma interessante.