Database management

This page describes CloudBase PostgreSQL database instance types, specifications, instance type upgrades, and specification changes. In the CloudBase console, select the PostgreSQL database for the target environment, then open the Configuration page. Available options are determined by the console.

Instance types

CloudBase PostgreSQL database provides the following instance types:

Instance type	Characteristics	Suitable scenarios
Shared instance	Compute usage is billed by actual use. No compute usage is incurred when there is no database access, scheduled job, function, or transaction processing. Storage is billed by actual usage.	Development, testing, personal projects, and non-critical workloads with infrequent calls and clear idle periods.
Dedicated instance	Provides full control over instance specifications and can scale compute specifications up or down as needed.	Workloads that need stable resources, continuous operation, or independent compute and storage capacity planning.

Shared instances do not require a fixed specification to be selected manually. Dedicated instances can adjust compute specifications and storage capacity according to workload. Choose an instance type based on how the workload runs, its resource-control requirements, and capacity plan.

Instance specifications

A dedicated instance specification includes compute specifications and storage capacity. Compute specifications are defined by a CPU and memory combination. Higher specifications generally support more concurrent connections and queries and provide a larger data cache. Exact specifications differ by region, instance type, and database version. Use the specification list displayed in the console.

The following compute specifications can currently be selected:

• 1 core 2 GiB
• 2 cores 4 GiB
• 2 cores 6 GiB
• 4 cores 8 GiB
• 8 cores 16 GiB
• 16 cores 32 GiB

Dedicated instance compute specifications can be scaled up or down as needed. Evaluate peak workloads before changing specifications, then monitor CPU, memory, and connection count after the change.

Use the following criteria when choosing a specification:

Consideration	Recommendation
Sustained high CPU usage	Select a specification with more CPU, or first reduce SQL computation through query optimization.
Memory pressure or low cache hit rate	Select a specification with more memory and review large queries, sorting, connection count, and index design.
Connection count approaching the limit	Review connection pool configuration first. Select a higher specification only when demand continues to grow. See connection management.
Large peak-to-trough workload variation	Select a specification based on peak load and capacity planning. Avoid sizing permanently for transient peaks.

Dedicated instances support compute specification changes and storage expansion. Shared instances run on demand and do not require manual instance specification configuration.

Billing model

CloudBase PostgreSQL database uses different methods to measure compute and storage usage for each instance type. For pricing and usage conversion rules, see CloudBase billable capability items. The console is the source of truth.

Compute usage

Shared instances: usage-based billing

Compute usage for shared instances is measured by actual database use:

• The measurement unit is five minutes, with each shared instance measured as 0.5 CPU cores.
• A five-minute interval is recorded as used when it contains database access or in-database scheduled jobs, functions, or transaction processing.
• For a used interval, compute usage is 0.5 * 5 / 60 = 0.04167 CU. If the database is used throughout an hour, total usage is 0.5 CU.
• A five-minute interval with no connection, read or write, scheduled job, function, or transaction processing does not incur compute usage.

Dedicated instances: specification-based billing

Compute usage for dedicated instances is determined by the instance specification and actual running time, whether or not the instance is accessed. Compute usage continues while the instance runs. After a specification change takes effect, usage is measured using the new specification.

For example, a dedicated instance with 1 CPU core and 2 GiB of memory incurs 1 CU for each hour it runs; an instance with 2 CPU cores and 4 GiB of memory incurs 2 CU for each hour it runs.

Storage usage

Shared instances: actual usage billing

Shared instances are measured by the storage space actually occupied by database data. Default tables and data consume a small amount of storage after database creation, so storage usage can occur even before business data is written.

Dedicated instances: allocated capacity billing

Dedicated instances are measured by allocated storage capacity and running time, not the amount of data actually written. Usage is calculated from the allocated capacity regardless of how much space is used.

For example, a dedicated instance allocated 20 GB of storage incurs 20 GB-hours for one hour of operation and 480 GB-hours for 24 hours of continuous operation. Storage can be expanded but cannot be reduced.

Upgrade the instance type

Upgrade the instance type to move a shared instance to a dedicated instance. After the upgrade, you can select and adjust dedicated instance specifications based on workload. Perform it during off-peak hours and prepare validation and rollback plans beforehand.

Pre-upgrade checklist

1. Confirm that the instance is available and that no specification change or other maintenance task is in progress.
2. Record the current connection endpoint, account permissions, allowlist, and network configuration. Confirm that the application uses connection pooling and reconnects after disconnection.
3. Check long-running transactions, batch jobs, and database connection count. Do not run high-risk or high-load operations during the upgrade window.
4. Notify affected teams and prepare checks for connections, reads, writes, and critical SQL after the upgrade.

Steps

1. Sign in to the CloudBase console and select the PostgreSQL database for the target environment.
2. Open the Configuration page, then select Upgrade to a dedicated instance in the instance type section.
3. Read the impact statement shown in the console and confirm the target configuration and pricing information.
4. Submit the upgrade request and wait for the instance to return to the available state.
5. After the upgrade, verify application connections, reads and writes, scheduled jobs, and monitoring metrics.

Connections can be interrupted briefly during an upgrade. Applications should retry failed requests and recreate connections automatically. Do not change core table structures or import large volumes of data during the upgrade.

Post-upgrade validation

• Verify that applications can connect with their existing connection information and complete critical read and write flows.
• Check that accounts, network access controls, RLS policies, and extensions work as expected.
• Review CPU, memory, connection count, slow queries, and error logs in logs and monitoring.
• Observe a full business cycle before removing any rate limiting or degradation measure retained for the upgrade.

Change specifications

Dedicated instances support compute specification changes and storage expansion. Neither operation changes the instance type.

Change compute specifications

Change the CPU and memory specifications of a dedicated instance when workload changes or monitoring shows insufficient resources.

Pre-change checklist

1. Use monitoring data to confirm that CPU, memory, or connection capacity is the bottleneck. Do not scale up solely because of a single slow query.
2. Confirm that the dedicated instance is available and that no upgrade or specification change is in progress.
3. Confirm that the target specification is available for the current region, instance type, and database version, and review the pricing change.
4. Schedule the change during off-peak hours. Production applications should support connection retry and connection-pool recovery.

Steps

1. Sign in to the CloudBase console and select the PostgreSQL database for the target environment.
2. Open the Configuration page, then select Change specification in the compute specification section.
3. Select the target CPU and memory specification, review the configuration and pricing, and submit the change.
4. Wait for the change to finish and confirm that the instance returns to the available state.
5. Check application connections, latency of critical endpoints, and database monitoring metrics. Continue improving connection pools and SQL based on the results.

Changing specifications can briefly interrupt database connections. Clients and servers must handle connection, transaction, and retry failures correctly. Do not treat an uncommitted transaction as successfully completed.

Recommendations

• Before scaling up, investigate slow queries, missing indexes, long-running transactions, and abnormal connections. More resources should not replace necessary optimization.
• Before scaling down, confirm that peak workloads, scheduled jobs, and batch workloads are stable on the target specification.
• After every change, monitor CPU, memory, connection count, slow queries, and application error rate. Make further changes only after metrics stabilize.
• Keep change records for critical workloads, including the time, original and target specifications, monitoring data, and validation results.

Expand storage capacity

Expand storage capacity for a dedicated instance when storage usage continues to increase or data and index growth approaches the current capacity. Storage capacity can only be increased and cannot be decreased. Available capacities, billing, and limits are determined by the console.

Pre-expansion checklist

1. Check current storage usage and its growth trend in logs and monitoring, then estimate growth from data and indexes.
2. Confirm that the dedicated instance is available and that no instance upgrade or specification change is in progress.
3. Confirm that the target storage capacity is available for the current region and instance specification, and review the pricing change.

Steps

1. Sign in to the CloudBase console and select the PostgreSQL database for the target environment.
2. Open the Configuration page, then select Expand storage capacity in the storage section.
3. Select the target storage capacity, review the configuration and pricing, and submit the change.
4. Wait for the expansion to finish and confirm that the instance returns to the available state.
5. Check storage usage, application reads and writes, and database monitoring metrics.

You do not need to change application connection information after expansion. Use the connection information displayed in the console as the source of truth and verify application connectivity.

FAQ

Does changing specifications change the connection endpoint

Usually, no. Use the connection information shown in the console as the source of truth, and verify application connectivity after the operation.

Can a dedicated instance be downgraded to a shared instance

Dedicated instances cannot be downgraded directly to shared instances. To downgrade, create an environment that uses a shared instance and migrate data from the original environment. After validating data, permissions, and application connections, switch the workload to the new environment.

Why does the application report connection errors during an upgrade or specification change

An instance type upgrade or compute specification change involves node switchover or restart, which briefly invalidates existing connections. Applications should use connection pools, retry policies, and idempotent design to prevent transient connection errors from causing duplicate writes or inconsistent data.

When should I change specifications rather than upgrade the instance type

Upgrade a shared instance to a dedicated instance when the workload needs stable resources or independent specification control. When a dedicated instance has insufficient CPU, memory, or storage capacity, change compute specifications or expand storage capacity first.