# Migrar do PostgreSQL para o Aurora DSQL
<a name="working-with-postgresql-compatibility-migration-guide"></a>

O Aurora DSQL foi projetado para ser [compatível com o PostgreSQL](working-with-postgresql-compatibility.md). Ele deve comportar recursos relacionais principais, como transações ACID, índices secundários, junções e operações DML padrão. A maioria das aplicações PostgreSQL existentes pode migrar para o Aurora DSQL com o mínimo de alterações.

Esta seção fornece orientação prática para migrar sua aplicação para o Aurora DSQL, incluindo compatibilidade de frameworks, padrões de migração e considerações arquitetônicas.

## Compatibilidade com frameworks e ORM
<a name="dsql-framework-compatibility"></a>

 O Aurora DSQL utiliza o protocolo de comunicação padrão do PostgreSQL, garantindo a compatibilidade com drivers PostgreSQL e frameworks. Os ORMs mais conhecidos funcionam com o Aurora DSQL com o mínimo ou nenhuma alteração. Consulte [Adaptadores e dialetos do Aurora DSQL](aws-sdks.md#aurora-dsql-adapters) para acessar implementações de referência e integrações de ORM disponíveis. 

## Padrões comuns de migração
<a name="working-with-postgresql-compatibility-migration-considerations"></a>

 Ao migrar do PostgreSQL para o Aurora DSQL, alguns recursos funcionam de forma diferente ou têm sintaxe alternativa. Esta seção fornece orientação sobre cenários comuns de migração. 

### Alternativas de operações DDL
<a name="dsql-ddl-alternatives"></a>

O Aurora DSQL fornece alternativas modernas às operações DDL tradicionais do PostgreSQL:

**Compilação de índice**  
Use `CREATE INDEX ASYNC` em vez de `CREATE INDEX` para criação de índices sem bloqueio.  
**Benefício:** criação de índice de tempo de inatividade zero em tabelas grandes.

**Remoção de dados**  
Use `DELETE FROM table_name` em vez de `TRUNCATE`.  
**Alternativa:** para a recriação completa da tabela, use `DROP TABLE` seguido de `CREATE TABLE`.

**Configuração do sistema**  
Como o Aurora DSQL é totalmente gerenciado, a configuração é feita automaticamente com base nos padrões de workload. Use a API ou o Console de Gerenciamento da AWS para gerenciar configurações de cluster.  
**Benefício:** não há necessidade de ajuste do banco de dados nem gerenciamento de parâmetros.

### Padrões de projeto do esquema
<a name="dsql-schema-design-patterns"></a>

Adapte estes padrões comuns do PostgreSQL para compatibilidade com o Aurora DSQL:

**Padrões de integração referenciais**  
O Aurora DSQL comporta relações e operações `JOIN` de tabelas. Para obter integridade referencial, implemente a validação na camada da aplicação. Esse design se alinha aos padrões dos bancos de dados distribuídos modernos, nos quais a validação da camada da aplicação oferece maior flexibilidade e evita gargalos de desempenho das operações em cascata.  
**Padrão:** implemente verificações de integridade referencial em sua camada de aplicação usando convenções de nomenclatura consistentes, lógica de validação e limites de transação. Muitas aplicações de alta escala preferem essa abordagem para melhor controle sobre o tratamento de erros e a performance.

**Tratamento de dados temporários**  
Use CTEs, subconsultas ou tabelas regulares com lógica de limpeza em vez de tabelas temporárias.  
**Alternativa:** crie tabelas com nomes específicos da sessão e limpe-as em sua aplicação.

## Noções básicas sobre as diferenças de arquitetura
<a name="working-with-postgresql-compatibility-architectural-differences"></a>

A arquitetura distribuída e sem servidor do Aurora DSQL difere intencionalmente do PostgreSQL tradicional em várias áreas. Essas diferenças possibilitam os principais benefícios de simplicidade e escala do Aurora DSQL.

### Modelo de banco de dados simplificado
<a name="dsql-simplified-database-model"></a>

**Único banco de dados por cluster**  
O Aurora DSQL fornece um banco de dados incorporado denominado `postgres` por cluster.  
**Dica de migração:** se sua aplicação usa vários bancos de dados, crie clusters do Aurora DSQL separados para separação lógica ou use esquemas em um único cluster.

**Sem tabelas temporárias**  
 Para o tratamento temporário de dados, é NECESSÁRIO usar expressões de tabela comuns (CTEs) e subconsultas, que oferecem alternativas flexíveis para consultas complexas.   
 **Alternativa:** use CTEs com cláusulas `WITH` para conjuntos de resultados temporários ou tabelas regulares com nomenclatura exclusiva para dados específicos da sessão. 

**Gerenciamento automático de armazenamento**  
O Aurora DSQL elimina os espaços de tabela e o gerenciamento manual do armazenamento. O armazenamento escala e otimizado automaticamente com base em seus padrões de dados.  
**Benefício:** não é necessário monitorar o espaço em disco, planejar a alocação de armazenamento nem gerenciar configurações de espaço de tabela.

### Padrões de aplicação moderna
<a name="dsql-modern-application-patterns"></a>

O Aurora DSQL incentiva padrões de desenvolvimento de aplicações modernas que melhoram a capacidade de manutenção e a performance:

**Lógica em nível de aplicação em vez de gatilhos de banco de dados**  
Para ter uma funcionalidade semelhante a um acionador, implemente a lógica orientada a eventos na camada da aplicação.  
**Estratégia de migração:** mova a lógica de gatilho para o código da aplicação, use arquiteturas orientadas por eventos com serviços da AWS, como o EventBridge, ou implemente trilhas de auditoria usando o registro em log de aplicações.

**Funções SQL para processamento de dados**  
O Aurora DSQL comporta funções baseadas em SQL, mas não a linguagens processuais, como PL/pgSQL.  
**Alternativa:** use funções SQL para transformações de dados ou mova uma lógica complexa para sua camada de aplicação ou funções do AWS Lambda.

**Controle de simultaneidade otimista em vez de bloqueio pessimista**  
O Aurora DSQL usa o controle otimista (OCC), uma abordagem sem bloqueio que difere de sistemas tradicionais baseados em bloqueios. Em vez de adquirir bloqueios que impedem outras transações, o Aurora DSQL permite que as transações prossigam sem bloqueio e detecta conflitos no momento da confirmação. Isso elimina deadlocks e impede que transações lentas bloqueiem outras operações.  
**Diferença fundamental:** quando ocorrem conflitos, o Aurora DSQL exibe um erro de serialização em vez de fazer as transações aguardarem bloqueios. Isso exige que as aplicações implementem uma lógica de repetição, semelhante à manipulação de tempos limite de bloqueio em bancos de dados tradicionais, mas os conflitos são resolvidos imediatamente, em vez de causar esperas de bloqueio.  
**Padrão de projeto:** implemente uma lógica de transação idempotente com mecanismos de repetição. Crie esquemas para minimizar a contenção usando chaves primárias aleatórias e distribuindo atualizações por todo o intervalo de chaves. Para obter detalhes, consulte [Controle de simultaneidade no Aurora DSQL](working-with-concurrency-control.md).

### Simplificações operacionais
<a name="dsql-operational-simplifications"></a>

O Aurora DSQL elimina muitas tarefas tradicionais de manutenção de banco de dados, reduzindo a sobrecarga operacional:

**Não é necessária manutenção manual**  
O Aurora DSQL gerencia automaticamente a otimização do armazenamento, a coleta de estatísticas e o ajuste de desempenho. Os comandos de manutenção tradicionais, como `VACUUM`, são gerenciados pelo sistema.  
**Benefício:** elimina a necessidade de janelas de manutenção do banco de dados, agendamento de vácuo e ajuste dos parâmetros do sistema.

**Escalabilidade e particionamento automático**  
O Aurora DSQL particiona e distribui automaticamente seus dados com base nos padrões de acesso. Use UUIDs ou IDs gerados pela aplicação para ter uma distribuição ideal.  
**Dica de migração:** remova a lógica de particionamento manual e deixe o Aurora DSQL lidar com a distribuição de dados. Use UUIDs ou IDs gerados pela aplicação para ter uma distribuição ideal. Se a aplicação exigir identificadores sequenciais, consulte [Sequências e colunas de identidade](sequences-identity-columns.md).

## Considerações sobre o Aurora DSQL para compatibilidade com o PostgreSQL
<a name="working-with-postgresql-compatibility-unsupported-limitations"></a>

O Aurora DSQL tem diferenças de suporte a recursos em relação ao PostgreSQL autogerenciado, que permitem sua arquitetura distribuída, operação sem servidor e escalabilidade automática. A maioria das aplicações funciona dentro dessas diferenças sem modificações.

Com relação a considerações gerais, consulte [Considerações para trabalhar com Amazon Aurora DSQL](considerations.md). Com relação a cotas e limites, consulte [Cotas de cluster e limites de banco de dados no Amazon Aurora DSQL](CHAP_quotas.md).
+ O Aurora DSQL usa um único banco de dados integrado por cluster, chamado `postgres`. Para separação lógica, crie clusters do Aurora DSQL separados ou use esquemas em um único cluster.
+ O banco de dados `postgres` usa a codificação de caracteres UTF-8, que oferece amplo suporte a caracteres internacionais.
+ O banco de dados usa somente o agrupamento `C`.
+ O Aurora DSQL usa `UTC` como fuso horário do sistema. O Postgres armazena todas as datas e horários com reconhecimento de fuso horário internamente em UTC. Você pode definir o parâmetro de configuração `TimeZone` para converter a forma como ele é exibido para o cliente e servir como padrão para a entrada do cliente que o servidor usará para converter em UTC internamente.
+ O nível de isolamento de transação é fixo em no PostgreSQL `Repeatable Read`.
+ As transações têm as seguintes restrições:
  + As operações de DDL e DML requerem transações separadas.
  + Uma transação pode incluir apenas uma instrução de DDL.
  + Uma transação pode modificar até 3 mil linhas, independentemente do número de índices secundários.
  + O limite de 3 mil linhas se aplica a todas as instruções de DML (`INSERT`, `UPDATE` e `DELETE`).
+ As conexões de banco de dados atingem o tempo limite após uma hora.
+ O Aurora DSQL gerencia permissões por meio de concessões em nível de esquema. Os usuários administradores criam esquemas usando `CREATE SCHEMA` e concedem acesso usando `GRANT USAGE ON SCHEMA`. Os usuários administradores gerenciam objetos no esquema público, enquanto os usuários não administradores criam objetos em esquemas criados pelo usuário para definir limites claros de propriedade. Para obter mais informações, consulte [Autorizar perfis de banco de dados a usar SQL no banco de dados](using-database-and-iam-roles.md#using-database-and-iam-roles-custom-database-roles-sql).

## Precisa de ajuda com a migração?
<a name="dsql-migration-feedback-link"></a>

Se você encontrar recursos essenciais para sua migração, mas que atualmente não são aceitos no Aurora DSQL, consulte [Fornecer feedback sobre o Amazon Aurora DSQL](providing-feedback.md) para acessar informações sobre como compartilhar feedback com a AWS.