Managed Postgres FAQ
Monitoring and metrics
How can I access metrics for my Managed Postgres instance?
You can monitor CPU, memory, IOPS, and storage usage directly from the ClickHouse Cloud console in the Monitoring tab of your Managed Postgres instance.
Query Performance Insights for detailed query analysis is coming soon.
Backup and recovery
What backup options are available?
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 documentation.
Infrastructure and automation
Is Terraform support available for Managed Postgres?
Terraform support for Managed Postgres isn't currently available. We recommend using the ClickHouse Cloud console to create and manage your instances.
Extensions and configuration
What extensions are supported?
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 documentation.
Can I customize PostgreSQL configuration parameters?
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 documentation.
If you need a parameter that isn't currently available, contact support to request it.
Connection pooling
Why am I seeing prepared statement does not exist errors through PgBouncer?
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:
Symptoms that often trace back to this same root cause:
- Bursts of
prepared statement does not existerrors, 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
BIGINTcolumn decoded as afloat64bit pattern) — this happens when a cached client-side plan reuses stale type/format codes against a backend that was never sent the matchingParse
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 for details on choosing between the pooled and direct endpoints.
What does the "max_client_conn" setting in PgBouncer mean, and how does it relate to max_connections in Postgres?
They control different things:
- Postgres
max_connectionscaps the number of backend connections to PostgreSQL itself. This is the expensive number — each backend uses memory and a process slot. - PgBouncer
max_client_conncaps 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.
Database capabilities
Can I create multiple databases and schemas?
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.
Is role-based access control (RBAC) supported?
You have full superuser access to your Managed Postgres instance, which allows you to create roles and manage permissions using standard PostgreSQL commands.
Enhanced RBAC features with console integration are planned for this year.
Upgrades
How are PostgreSQL version upgrades handled?
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 documentation.
Migration
What tools are available for migrating to Managed Postgres?
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 guide.
- Logical replication: For larger databases requiring minimal downtime. See the Logical replication guide.
- PeerDB: For CDC-based replication from other Postgres sources. See the PeerDB migration guide.
A fully managed migration experience is coming soon.
