The rate of the number of new connections that you create on your Cloud SQL for PostgreSQL instance, per second. Cloud SQL calculates and displays this metric per database.

This metric is available for PostgreSQL version 14 and later.

The number of connections for each wait event type in a Cloud SQL for PostgreSQL instance.

The number of wait events in a Cloud SQL for PostgreSQL instance. The dashboard displays this metric aswait event name:wait event type.

The number of transactions in thecommit androllback states in a Cloud SQL for PostgreSQL instance.

The memory components available to the database. The value for each memory component is calculated as the percentage of the total memory available to the database.

The maximum replication lag (in bytes) among all the databases on the external server (ES) replica.

The aggregated query latency distribution by P99, P95, and P50 per user and database.

Only available for instances withquery insights enabled.

The accumulated query execution time per database, user, or client address. This is the sum of CPU time, I/O wait time, lock wait time, process context switch, and scheduling for all processes involved in query execution.

Only available for instances withquery insights enabled.

The current CPU utilization represented as a percentage of the reserved CPU that's currently in use.

The breakdown of instance disk usage by data types, includingdata,binlog, andtmp_data.

This metric helps you understand your storage costs. For more information about storage usage charges, seeStorage and networking pricing.

Point-in-time recovery (PITR) uses write-ahead log (WAL) archiving. These logs update regularly and use storage space. Write-ahead logs are automatically deleted with their associated automatic backup, which generally happens after about 7 days.

If the size of your write-ahead logs is causing an issue for your instance, you can increase your storage size, but the write-ahead log size increase in disk usage might be temporary. To avoid unexpected storage issues, Google recommends enablingautomatic storage increases when using PITR.

To delete the logs and recover storage, you can disable point-in-time recovery. Note, however, that decreasing the storage used does not shrink the size of the storage provisioned for the instance.

Temp data is included in the storage usage metric. Temp data is removed as part of maintenance and is allowed to increase beyond user-defined capacity limits to avoid a disk full event, at no charge to the user.

A newly created database uses about 100 MB for system tables and files.

The breakdown of instance disk usage by data types, includingdata,binlog, andtmp_data.

This metric helps you understand your storage costs. For more information about storage usage charges, seeStorage and networking pricing.

Point-in-time recovery useswrite-ahead logging (WAL) archiving. For new Cloud SQLinstances that have point-in-time recovery enabled or for existing instances thatenable point-in-time recovery after this feature for storing WAL logs in Cloud Storage is available, logs will no longerbe stored on disk; instead they'll be stored inCloud Storage in the same region as the instances.

To see whether aninstance's logs are stored in Cloud Storage, check thebytes_used_by_data_type metric for the instance. If thevalue for thearchived_wal_log data type is0, theinstance's logs are stored in Cloud Storage.

All other existing instances that have point-in-time recovery enabledcontinue to have their logs stored on disk. The change to storing logs inCloud Storage will be made available at a later time.

The write-ahead logs used in point-in-time recovery are deleted automatically with their associated automatic backup, which generally happens after the value set fortransactionLogRetentionDays is met. This is the number of days of transaction logs that Cloud SQL retains for point-in-time recovery, from 1 to 7.

For instances that have write-ahead logs stored in Cloud Storage,the logs are stored in the same region as the primary instance. This log storage(up to seven days, the maximum length for point-in-time recovery) generates no additional cost per instance.

If your instance has point-in-time recovery enabled, and if the size of your write-ahead logs on disk is causing an issue for your instance, then disable point-in-time recovery and re-enable it to ensure that new logs are stored in Cloud Storage in the same region as the instance. This deletes existing write-ahead logs, so you can't perform a point-in-time restore earlier than the time that you re-enabled point-in-time recovery. However, although the existing logs are deleted, the disk size remains the same.

To avoid unexpected storage issues, we recommend enablingautomatic storage increases for all instances when using point-in-time recovery. This recommendation applies only if your instance has point-in-time recovery enabled and your logs are stored on disk.

To delete the logs and recover storage, you can disable point-in-time recovery. Note, however, that decreasing the write-ahead logs used doesn't shrink the size of the disk provisioned for the instance.

Temp data is included in the storage usage metric. Temp data is removed as part of maintenance and is allowed to increase beyond user-defined capacity limits to avoid a disk full event, at no charge to the user.

A newly created database uses about 100 MB for system tables and files.

The Number of Reads metric indicates the number of read operations served from disk that do not come from cache. You can use this metric to understand whether your instance is correctly sized for your environment. If needed, you can move to a larger machine type to serve more requests from cache and reduce latency.

The Number of Writes metric indicates the number of write operations to disk. Write activity is generated even if your application is not active because Cloud SQL instances, barring replicas, write to a system table approximately every second.

The number of connections grouped by these statuses:idle,active,idle_in_transaction,idle_in_transaction_aborted,disabled, andfastpath_function_call.

For information about these statuses, see thestate text row in thepg_stat_activity documentation.

The number of connections held by the database instance.

The network traffic in terms of the number of ingress bytes (bytes received) and egress bytes (bytes sent) to and from the instance, respectively.

The breakdown of I/O wait time for SQL statements by read and write types.

Only available for instances withquery insights enabled.

The number of deadlocks per database.

The number of blocks read per second from the disk and from the buffer cache.

The number of rows processed per operation per second.

The number of rows for each database state. Cloud SQL reports this metric if the number of databases in the instance is less than 50.

The age of the oldest transaction that's blocking the vacuum operation.

The number of write-ahead log files that were successfully or unsuccessfully archived per minute.

The percentage of transaction IDs used in the instance.

The number of connections to the Cloud SQL instance, grouped by applications.

Connections without an application name are grouped asUnknown.

• Rows fetched: postgresql/tuples_fetched_count
• Rows returned: postgresql/tuples_returned_count
• Rows written: postgresql/tuples_processed_count

• Rows fetched is the number of rows fetched as a result of queries in the instance.
• Rows returned is the number of rows scanned while processing the queries in the instance.
• Rows written is the number of rows written in the instance while performing insert, update, and delete operations.

If the difference between rows returned and rows fetched is so large that their values aren't shown in the same scale, then the value of rows fetched is shown as 0 because it's negligible compared to the value of rows returned.

The total amount of data (in bytes) used for query execution and performing algorithms such as join and sort.

The number of temporary files used for query execution and performing algorithms such as join and sort.