---
title: "Tuning database configuration parameters"
slug: "database-configuration-tuning"
source: "https://app.cloudpe.com/help/database-configuration-tuning"
updated: "2026-08-30T19:03:44.169Z"
---

# Tuning database configuration parameters

## Overview

Every managed database cluster runs with a set of engine configuration parameters (for example connection limits, memory buffers and query-logging thresholds). The **Configuration** tab on a cluster's detail page shows the parameters CloudPe exposes for that engine and lets you override the defaults without opening a shell on the database node.

Configuration overrides are stored against the cluster and pushed to the guest agent running on each node, so the values survive node maintenance. Managed Databases is a beta feature, and the set of tunable parameters depends on the cluster's engine.

## Before you start

- **Databases** appears under the PLATFORM group in the sidebar and is marked beta.
- You need the `databases:read` permission to view the current configuration and `databases:update` to change it.
- You must be a member of the organization that owns the cluster — DBaaS clusters are authorized at organization scope.
- The cluster must already exist and be reachable; parameter changes are applied through the node's management agent, so a cluster that is still provisioning or unreachable cannot accept them.
- Note which parameters require an engine restart before you change them in production. Restart-required parameters take effect only after the engine restarts, which briefly interrupts connections.

## Steps

1. Open **Databases** in the sidebar and select the cluster you want to tune. The cluster detail page opens on **Cluster Details**.
2. Switch to the **Configuration** tab. The tab lists the parameters CloudPe exposes for the cluster's engine, together with the value currently in effect.

   ![](/kb/databases/database-configuration-tuning-01-configuration-tab.png)

3. Change the values you want to override. Leave everything else untouched — only the parameters you send are modified; the rest keep their current values.
4. Apply the change. The console submits the changed parameters to the cluster.
5. Use **Refresh** to re-read the configuration from the cluster and confirm the new values are in effect.
6. Open the **Events** tab to see the audit entry recorded for the configuration change, and the **Monitoring** tab to watch connection and memory behaviour after the change.

## API

Both configuration endpoints are cluster-scoped and require a bearer token.

| Method | Path | Permission |
|---|---|---|
| GET | `/api/v1/databases/{cluster_id}/config` | `databases:read` |
| PATCH | `/api/v1/databases/{cluster_id}/config` | `databases:update` |

Read the current configuration:

```bash
curl -X GET "https://app.cloudpe.com/api/v1/databases/<cluster_id>/config" \
  -H "Authorization: Bearer <API_KEY>"
```

Update one or more parameters. The request body takes a single required `parameters` object whose keys are parameter names valid for the cluster's engine:

```bash
curl -X PATCH "https://app.cloudpe.com/api/v1/databases/<cluster_id>/config" \
  -H "Authorization: Bearer <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "parameters": {
      "<parameter_name>": "<value>"
    }
  }'
```

To confirm the cluster state before and after a change, use `GET /api/v1/databases/{cluster_id}` and review `GET /api/v1/databases/{cluster_id}/events`.

## Limits & billing

- Configuration changes carry no separate charge. The cluster continues to be billed hourly for its plan and any extra storage, regardless of the parameters you set.
- Tuning does not change the plan's vCPU, RAM or disk allocation, so raising a memory-related parameter cannot give the node more memory than its plan provides. If a workload needs more resources than the plan supplies, the cluster's plan — not its configuration — is what has to change.
- Only parameters that CloudPe exposes for the engine can be set; arbitrary engine variables are not accepted.

## Troubleshooting

| Error | Cause | What to do |
|---|---|---|
| `Cluster not found` | The cluster ID in the request path does not resolve, or it belongs to an organization you are not a member of. | Re-open the cluster from **Databases** and take the ID from the URL. Confirm you are working in the organization that owns the cluster. |
| `User has no organization` | The calling account is not attached to an organization, so no cluster can be resolved for it. | Join or create an organization from **Organizations**, then retry. |

If a value is accepted but the engine still reports the old setting, check whether the parameter requires a restart — restart-required parameters are staged and take effect only after the engine restarts.

## FAQ

**Does changing a parameter restart my database?**
Only for parameters that the engine cannot change at runtime. Dynamic parameters apply immediately; restart-required parameters take effect after the engine restarts, which briefly interrupts connections.

**Do I have to send every parameter when I update one?**
No. Send only the parameters you want to change in the `parameters` object. Anything you omit keeps its current value.

**How do I revert a change?**
Set the parameter back to its previous value and apply the change again. Use **Refresh** on the **Configuration** tab to confirm the value in effect.

**Which parameters are available for my cluster?**
The list depends on the engine the cluster runs. Read `GET /api/v1/databases/{cluster_id}/config` or open the **Configuration** tab to see what is exposed for that cluster.

**Can I tune each node separately?**
No. Configuration is managed at the cluster level and applied to the cluster's nodes; there is no per-node override in the console or the API.

## Related

- [Creating and managing PostgreSQL clusters](/help/dbaas-postgresql-clusters)
- [Managing database users and databases](/help/dbaas-user-db-management)