FAQ

The following are a few FAQ to provide insight into the PostgreSQL product.

DBaaS offers PostgreSQL on virtual servers. Cloud Cubes support may be introduced in the future.

PostgreSQL supports ASYNCHRONOUS and STRICTLY_ASYNCHRONOUS replication modes. SYNCHRONOUS mode is deprecated. You can set the replication mode when creating or updating a cluster in the DCD (listed as Synchronization mode) or through the API. In the v2 API, the property is named replicationMode. Existing v1 clusters using SYNCHRONOUS mode can switch to a supported mode using the API.

The supported versions depend on the API version you are using:

PostgreSQL 17 and 18 are only available through the v2 API. If you are on v1 and want to use a newer version, you must migrate to v2.

In PostgreSQL v1, you first Create a user and then specify that username in the owner filed when you Create a database. It allows you to associate a user account with a PostgreSQL database.

In PostgreSQL v2, database creation is integrated into cluster provisioning. Instead of creating users and databases separately, you can create both a new user and a new database as part of the Create Cluster API request.

Legacy clusters are existing PostgreSQL v1 clusters. They are shown as Legacy Clusters in the PostgreSQL cluster overview in the DCD. Existing v1 clusters will be automatically migrated to the new v2 infrastructure and no user action is required. We will notify you before the migration.

Yes. IONOS CLOUD DBaaS PostgreSQL provides a managed connection pooler (pgbouncer) that you can configure when creating or updating a cluster.

In the DCD, select the Connection Pooler mode during cluster setup or update. For more information, see Create a PostgreSQL Cluster.

In the PostgreSQL v2 API, set the connectionPooler property to "TRANSACTION", "SESSION", or omit it to disable pooling. For more information, see Activate a PostgreSQL Connection Pooler.

Depending on the library you are using, you get the following error:

Failed to create DB connection: addr x.x.x.x:5432: connection refused.

The best way to manage connections is to have your application maintain a pool of at least 10-20 connections. It is not considered good practice to have many DB connections. However, letting the user configure max_connections themselves in the future is an option.

Yes. The max_connections value is calculated based on the RAM size of your cluster instances; increasing RAM per instance raises the connection limit. Note that 11 connections are reserved for internal platform use. If your application creates many short-lived connections, allowing the managed connection pooler (pgbouncer) is recommended to reduce the number of direct connections to PostgreSQL. For more information, see Connection Limits.

We provide automated backups in IONOS CLOUD. If you want to use other backup options, you may use a client-side tool, such as pg_dump.

If you are receiving an error message, Parameter out of bounds: The recovery target time is before the newest basebackup., check the earliestRecoveryTargetTime of your backup. Your target time for the restore needs to be after this timestamp. You can use an earlier backup with earliestRecoveryTargetTime for your cluster if you have one.

If the earliestRecoveryTargetTime is missing in your backup, the cluster from where you want to restore wasn't able to do a base backup. It can happen when you quickly delete a newly created cluster, since the base backup will be triggered up to a minute after the cluster is available.

The number of standby nodes (in addition to the primary node) doesn't really matter. If you have one or ten, it makes no difference. Synchronous modes are slower in write performance due to increased communication latency between a primary and a standby node.

In the DCD, toggle Enable metrics in the observability settings during cluster setup or update. In the v2 API, set metricsEnabled to true on the cluster. The Monitoring Service must be activated for your contract before metrics can be collected. For a step-by-step guide, see Monitor PostgreSQL Databases.

The PostgreSQL v2 API is a modernized, future-proof, and developer-friendly REST interface designed to provision and manage highly available PostgreSQL clusters. It introduces refined resource modeling, region-specific routing, and OpenAPI best-practice error handling. It is a new engine architecture of IONOS CLOUD PostgreSQL and does not refer to Supported PostgreSQL versions.

To align with modern security best practices, the v2 API requires API tokens (tokenAuth). Legacy basic authentication (basicAuth), which is available in PostgreSQL v1, is no longer supported.

The PostgreSQL v2 API utilizes multiple region-specific endpoints. You must direct your requests to the specific region where your database is deployed. For information on supported regions and their corresponding endpoints, see Endpoints.

Yes. The PostgreSQL v2 API is in General Availability (GA) phase starting May 18, 2026, and is supported for production workloads across all IONOS CLOUD regions where DBaaS PostgreSQL is offered. No prior whitelisting or contract activation is required.

No, you cannot. The v2 API intentionally denies this access. If you attempt to connect to it using your v2 cluster credentials, you receive a permission-denied error for the postgres database. You must instead connect to the specific database you defined within your cluster configuration during provisioning.

The PostgreSQL v2 API introduces the "Ensure" pattern for cluster management. By utilizing PUT semantics such as PUT /clusters/{clusterId}, you can safely and idempotently create a new cluster or update an existing one to match your desired state. Non-present data will be filled with defaults.

You define your main user credentials, including the username, password, and database name, directly within the credentials property of your cluster payload during provisioning or when modifying the cluster.

Backups have been elevated to a dedicated top-level /backups endpoint, rather than being strictly nested under individual clusters. Additionally, the API introduces BackupLocations (/backup-locations) as an explicit resource, allowing you to query and configure the geographic safety of your backups.

Yes. Every listing endpoint in the v2 API, such as /clusters or /backups supports standardized pagination (using limit and offset) and robust filtering. It allows you to search your resources by attributes such as filter.state, filter.name, or filter.clusterId.

No, the explicit /logs endpoint available in v1 has been removed in the PostgreSQL v2 specification, indicating a shift in how operational observability and log access are managed.

Use the cluster metrics reporting to monitor the health of the cluster. The Retrieve Cluster API only provides the status of the cluster.

In Create Cluster or Ensure Cluster, set the logsEnabled to true to view the logs reporting and set the metricsEnabled to true to view the metrics reporting.

To activate the Logging Service, use the Ensure Central Logging API with enabled parameter set to true.

To activate the Monitoring Service, use the Ensure Central Monitoring API with the enabled parameter set to true.