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

# Managed Postgres FAQ

> Frequently asked questions about 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>;
};

<h2 id="monitoring-and-metrics">
  Monitoring and metrics
</h2>

<h3 id="metrics-access">
  How can I access metrics for my Managed Postgres instance?
</h3>

You can monitor CPU, memory, IOPS, and storage usage directly from the ClickHouse Cloud console in the **Monitoring** tab of your Managed Postgres instance.

<Note>
  Query Performance Insights for detailed query analysis is coming soon.
</Note>

<h2 id="backup-and-recovery">
  Backup and recovery
</h2>

<h3 id="backup-options">
  What backup options are available?
</h3>

Managed Postgres includes automatic daily backups with continuous WAL archiving, enabling point-in-time recovery to any moment within a 7-day retention window. Backups are stored in S3.

For complete details on backup frequency, retention, and how to perform point-in-time recovery, see the [Backup and restore](/products/managed-postgres/backup-and-restore) documentation.

<h2 id="infrastructure-and-automation">
  Infrastructure and automation
</h2>

<h3 id="terraform-support">
  Is Terraform support available for Managed Postgres?
</h3>

Terraform support for Managed Postgres isn't currently available. We recommend using the ClickHouse Cloud console to create and manage your instances.

<h2 id="extensions-and-configuration">
  Extensions and configuration
</h2>

<h3 id="extensions-supported">
  What extensions are supported?
</h3>

Managed Postgres includes 100+ PostgreSQL extensions, including popular ones like PostGIS, pgvector, pg\_cron, and many more. For the complete list of available extensions and installation instructions, see the [Extensions](/products/managed-postgres/extensions) documentation.

<h3 id="config-customization">
  Can I customize PostgreSQL configuration parameters?
</h3>

Yes, you can modify PostgreSQL and PgBouncer configuration parameters through the **Settings** tab in the console. For details on available parameters and how to change them, see the [Settings](/products/managed-postgres/settings) documentation.

<Tip>
  If you need a parameter that isn't currently available, contact [support](https://clickhouse.com/support/program) to request it.
</Tip>

<h2 id="connection-pooling">
  Connection pooling
</h2>

<h3 id="prepared-statement-errors">
  Why am I seeing `prepared statement does not exist` errors through PgBouncer?
</h3>

Managed Postgres runs PgBouncer in **transaction pooling** mode. In this mode, a backend Postgres connection is only assigned to your client for the duration of a single transaction, then returned to the pool — the next transaction from the same client may land on a different backend.

That breaks **server-side prepared statements**, which are tied to the specific backend that ran the `PREPARE` (or the extended-query `Parse`). When the matching `Execute` lands on a different backend, you get errors like:

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

Symptoms that often trace back to this same root cause:

* Bursts of `prepared statement does not exist` errors, especially during backfills or high-concurrency writes
* Inserts that appear to "silently fail" — the statement errors, the driver retries, and a batch can end up partially applied or dropped
* Returned values with the wrong type (for example, a `BIGINT` column decoded as a `float64` bit pattern) — this happens when a cached client-side plan reuses stale type/format codes against a backend that was never sent the matching `Parse`

**Fix: disable server-side prepared statements in your driver.** The exact knob depends on your client library:

| Driver                           | Setting                                                                                |
| -------------------------------- | -------------------------------------------------------------------------------------- |
| **pgx** (Go)                     | `statement_cache_capacity=0` and `default_query_exec_mode=exec` (or `simple_protocol`) |
| **psycopg3** (Python)            | `prepare_threshold=None`                                                               |
| **asyncpg** (Python)             | `statement_cache_size=0`                                                               |
| **JDBC** (Java)                  | `prepareThreshold=0`                                                                   |
| **node-postgres / pg** (Node.js) | Don't pass a `name` to `query()` (named queries become server-prepared)                |

If your workload depends on prepared statements, connect **directly to PostgreSQL** (port 5432) instead of going through the PgBouncer pooler — direct connections support prepared statements normally. See [Connection](/products/managed-postgres/connection) for details on choosing between the pooled and direct endpoints.

<h3 id="pgbouncer-vs-pg-connections">
  What does the "max\_client\_conn" setting in PgBouncer mean, and how does it relate to `max_connections` in Postgres?
</h3>

They control different things:

* **Postgres `max_connections`** caps the number of **backend** connections to PostgreSQL itself. This is the expensive number — each backend uses memory and a process slot.
* **PgBouncer `max_client_conn`** caps the number of **client** connections that can be open to the pooler at once. PgBouncer multiplexes these many client connections onto a much smaller set of backend connections.

A typical Managed Postgres instance is configured so PgBouncer accepts roughly **10× more client connections than there are Postgres backends** (e.g. 5000 client / 500 backend). If you see connection errors at the pooler, you're far more likely to be hitting a per-pool backend limit (`default_pool_size`) than the headline client limit.

<h2 id="database-capabilities">
  Database capabilities
</h2>

<h3 id="multiple-databases-schemas">
  Can I create multiple databases and schemas?
</h3>

Yes. Managed Postgres provides full native PostgreSQL functionality, including support for multiple databases and schemas within a single instance. You can create and manage databases and schemas using standard PostgreSQL commands.

<h3 id="rbac-support">
  Is role-based access control (RBAC) supported?
</h3>

You have full superuser access to your Managed Postgres instance, which allows you to create roles and manage permissions using standard PostgreSQL commands.

<Note>
  Enhanced RBAC features with console integration are planned for this year.
</Note>

<h2 id="upgrades">
  Upgrades
</h2>

<h3 id="version-upgrades">
  How are PostgreSQL version upgrades handled?
</h3>

Both minor and major version upgrades are performed via failover and typically result in only a few seconds of downtime. You can configure a maintenance window to control when upgrades are applied. For complete details, see the [Upgrades](/products/managed-postgres/upgrades) documentation.

<h2 id="migration">
  Migration
</h2>

<h3 id="migration-tools">
  What tools are available for migrating to Managed Postgres?
</h3>

Managed Postgres supports several migration approaches:

* **pg\_dump and pg\_restore**: For smaller databases or one-time migrations. See the [pg\_dump and pg\_restore](/products/managed-postgres/migrations/pg_dump-pg_restore) guide.
* **Logical replication**: For larger databases requiring minimal downtime. See the [Logical replication](/products/managed-postgres/migrations/logical-replication) guide.
* **PeerDB**: For CDC-based replication from other Postgres sources. See the [PeerDB migration](/products/managed-postgres/migrations/peerdb) guide.

<Note>
  A fully managed migration experience is coming soon.
</Note>