> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-fix-nav-issues.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# FAQ do Managed Postgres

> Perguntas frequentes sobre ClickHouse Managed Postgres

export const galaxyOnClick = eventName => () => {
  try {
    if (typeof window !== "undefined" && window.galaxy && eventName) {
      window.galaxy.track(eventName, {
        interaction: "click"
      });
    }
  } catch (e) {}
};

export const BetaBadge = ({link, galaxyTrack, galaxyEvent}) => {
  if (link) {
    return <a href={link} target="_blank" rel="noopener noreferrer" className="betaBadge" onClick={galaxyTrack && galaxyEvent ? galaxyOnClick(galaxyEvent) : undefined}>
                <Icon />
                <span>Beta</span>
            </a>;
  }
  return <div className="betaBadge">
            <Icon />
            <span>
                Beta feature. 
                <u>
                    <a href="/docs/beta-and-experimental-features#beta-features">
                        Learn more.
                    </a>
                </u>
            </span>
        </div>;
};

<div id="monitoring-and-metrics">
  ## Monitoramento e métricas
</div>

<div id="metrics-access">
  ### Como posso acessar as métricas da minha instância do Managed Postgres?
</div>

Você pode monitorar o uso de CPU, memória, IOPS e armazenamento diretamente no console do ClickHouse Cloud, na aba **Monitoring** da sua instância do Managed Postgres.

<Note>
  O Query Performance Insights, para análise detalhada de consultas, estará disponível em breve.
</Note>

<div id="backup-and-recovery">
  ## Backup e recuperação
</div>

<div id="backup-options">
  ### Quais opções de backup estão disponíveis?
</div>

O Managed Postgres inclui backups automáticos diários com arquivamento contínuo de WAL, permitindo a recuperação para qualquer momento dentro de uma janela de retenção de 7 dias. Os backups são armazenados no S3.

Para obter detalhes completos sobre a frequência dos backups, a retenção e como realizar a recuperação para um ponto no tempo, consulte a documentação de [Backup e restauração](/pt-BR/products/managed-postgres/backup-and-restore).

<div id="infrastructure-and-automation">
  ## Infraestrutura e automação
</div>

<div id="terraform-support">
  ### O Managed Postgres tem suporte ao Terraform?
</div>

No momento, o Managed Postgres ainda não oferece suporte ao Terraform. Recomendamos usar o console do ClickHouse Cloud para criar e gerenciar suas instâncias.

<div id="extensions-and-configuration">
  ## Extensões e configuração
</div>

<div id="extensions-supported">
  ### Quais extensões são suportadas?
</div>

O Managed Postgres inclui mais de 100 extensões do PostgreSQL, incluindo extensões populares como PostGIS, pgvector, pg\_cron e muitas outras. Para ver a lista completa de extensões disponíveis e as instruções de instalação, consulte a documentação de [Extensões](/pt-BR/products/managed-postgres/extensions).

<div id="config-customization">
  ### Posso personalizar os parâmetros de configuração do PostgreSQL?
</div>

Sim, você pode modificar os parâmetros de configuração do PostgreSQL e do PgBouncer pela aba **Settings** no console. Para saber mais sobre os parâmetros disponíveis e como alterá-los, consulte a documentação de [Settings](/pt-BR/products/managed-postgres/settings).

<Tip>
  Se precisar de um parâmetro que ainda não esteja disponível, entre em contato com o [suporte](https://clickhouse.com/support/program) para solicitá-lo.
</Tip>

<div id="connection-pooling">
  ## Pool de conexões
</div>

<div id="prepared-statement-errors">
  ### Por que estou vendo erros `prepared statement does not exist` ao passar pelo PgBouncer?
</div>

O Managed Postgres executa o PgBouncer no modo de **pooling de transações**. Nesse modo, uma conexão de backend do Postgres é atribuída ao cliente apenas durante uma única transação e depois retorna ao pool — a transação seguinte do mesmo cliente pode cair em um backend diferente.

Isso quebra as **prepared statements no servidor**, que ficam vinculadas ao backend específico que executou o `PREPARE` (ou o `Parse` da consulta estendida). Quando o `Execute` correspondente cai em um backend diferente, você recebe erros como:

```text theme={null}
ERROR:  prepared statement "..." does not exist
ERROR:  unnamed prepared statement does not exist
```

Sintomas que geralmente têm a mesma causa raiz:

* Picos de erros `prepared statement does not exist`, especialmente durante backfills ou escritas com alta concorrência
* Inserts que parecem "falhar silenciosamente" — a instrução gera erro, o driver faz novas tentativas, e um batch pode acabar sendo aplicado parcialmente ou descartado
* Valores retornados com o tipo errado (por exemplo, uma coluna `BIGINT` decodificada como um padrão de bits `float64`) — isso acontece quando um plano em cache no cliente reutiliza códigos de tipo/formato desatualizados em um backend para o qual o `Parse` correspondente nunca foi enviado

**Correção: desative as prepared statements no servidor no seu driver.** A configuração exata depende da sua biblioteca cliente:

| Driver                           | Configuração                                                                             |
| -------------------------------- | ---------------------------------------------------------------------------------------- |
| **pgx** (Go)                     | `statement_cache_capacity=0` e `default_query_exec_mode=exec` (ou `simple_protocol`)     |
| **psycopg3** (Python)            | `prepare_threshold=None`                                                                 |
| **asyncpg** (Python)             | `statement_cache_size=0`                                                                 |
| **JDBC** (Java)                  | `prepareThreshold=0`                                                                     |
| **node-postgres / pg** (Node.js) | Não passe um `name` para `query()` (consultas nomeadas se tornam preparadas no servidor) |

Se a sua carga de trabalho depende de prepared statements, conecte-se **diretamente ao PostgreSQL** (porta 5432) em vez de passar pelo pooler PgBouncer — conexões diretas oferecem suporte normal a prepared statements. Veja [Conexão](/pt-BR/products/managed-postgres/connection) para saber como escolher entre os endpoints com pool e os diretos.

<div id="pgbouncer-vs-pg-connections">
  ### O que significa a configuração "max\_client\_conn" no PgBouncer e como ela se relaciona com `max_connections` no Postgres?
</div>

Elas controlam coisas diferentes:

* **Postgres `max_connections`** limita o número de conexões de **backend** com o próprio PostgreSQL. Esse é o número mais custoso — cada backend consome memória e um slot de processo.
* **PgBouncer `max_client_conn`** limita o número de conexões de **cliente** que podem ficar abertas simultaneamente para o pooler. O PgBouncer multiplexa essas várias conexões de cliente em um conjunto muito menor de conexões de backend.

Uma instância típica de Managed Postgres é configurada para que o PgBouncer aceite cerca de **10× mais conexões de cliente do que o número de backends do Postgres** (por exemplo, 5000 clientes / 500 backends). Se você vir erros de conexão no pooler, é muito mais provável que esteja esbarrando em um limite de backend por pool (`default_pool_size`) do que no limite total de clientes.

<div id="database-capabilities">
  ## Recursos do banco de dados
</div>

<div id="multiple-databases-schemas">
  ### Posso criar vários bancos de dados e esquemas?
</div>

Sim. O Managed Postgres oferece todos os recursos nativos do PostgreSQL, incluindo suporte a vários bancos de dados e esquemas em uma única instância. Você pode criar e gerenciar bancos de dados e esquemas usando os comandos padrão do PostgreSQL.

<div id="rbac-support">
  ### Há suporte a Controle de Acesso Baseado em Funções (RBAC)?
</div>

Você tem acesso completo de superusuário à sua instância do Managed Postgres, o que permite criar funções e gerenciar permissões usando os comandos padrão do PostgreSQL.

<Note>
  Recursos avançados de RBAC com integração ao Console estão planejados para este ano.
</Note>

<div id="upgrades">
  ## Atualizações de versão
</div>

<div id="version-upgrades">
  ### Como as atualizações de versão do PostgreSQL são gerenciadas?
</div>

Tanto as atualizações de versões secundárias quanto as de versões principais são realizadas por failover e normalmente resultam em apenas alguns segundos de indisponibilidade. Você pode configurar uma janela de manutenção para controlar quando as atualizações são aplicadas. Para mais detalhes, consulte a documentação de [Atualizações](/pt-BR/products/managed-postgres/upgrades).

<div id="migration">
  ## Migração
</div>

<div id="migration-tools">
  ### Quais ferramentas estão disponíveis para migrar para o Managed Postgres?
</div>

O Managed Postgres oferece suporte a várias abordagens de migração:

* **pg\_dump and pg\_restore**: Para bancos de dados menores ou migrações únicas. Consulte o guia [pg\_dump and pg\_restore](/pt-BR/products/managed-postgres/migrations/pg_dump-pg_restore).
* **Logical replication**: Para bancos de dados maiores que exigem o mínimo de indisponibilidade. Consulte o guia [Replicação lógica](/pt-BR/products/managed-postgres/migrations/logical-replication).
* **PeerDB**: Para replicação baseada em CDC a partir de outras fontes do Postgres. Consulte o guia [Migração com PeerDB](/pt-BR/products/managed-postgres/migrations/peerdb).

<Note>
  Uma experiência de migração totalmente gerenciada estará disponível em breve.
</Note>