You can use the storage usage metric to help you understand your storage costs. For more information about storage usage charges, see Storage and Networking Pricing.

Point-in-time recovery uses write-ahead logging (WAL) archiving. For new Cloud SQL instances that have point-in-time recovery enabled or for existing instances that enable point-in-time recovery after this feature for storing WAL logs in Cloud Storage is available, logs are no longer stored on disk; instead they're stored in Cloud Storage in the same region as the instances.

To see whether an instance's logs are stored in Cloud Storage, check the bytes_used_by_data_type metric for the instance. If the value for the archived_wal_log data type is 0, the instance's logs are stored in Cloud Storage.

After you use a PostgreSQL client such as psql or pgAdmin to connect to a database of the instance, run the following command: show archive_command. If any WALs are archived in Cloud Storage, then you see -async_archive -remote_storage.

All other existing instances that have point-in-time recovery enabled continue to have their logs stored on disk. The change to storing logs in Cloud Storage is 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 for transactionLogRetentionDays is met. This is the number of days of transaction logs that Cloud SQL retains for point-in-time recovery, from 1 to 35 for Cloud SQL Enterprise Plus edition and 1 to 7 for Cloud SQL Enterprise edition.

When you restore a backup on a Cloud SQL instance before enabling point-in-time recovery, you lose the WAL logs that allow the operability of point-in-time recovery.

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 deactivate 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 enabling automatic 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 deactivate 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.

Data usage is included in the storage usage metric. As part of data usage, when a transaction modifies a database, before Cloud SQL modifies the original data, a copy is made of this data. The copy of the data is undo data.

You can use this metric to monitor whether your instance has sufficient CPU for your application needs. If this value is running too high, you can increase the size of your machine type to give your instance more CPU capability.

The amount of memory being used by your instance.

The Number of Reads metric is the number of read operations served from disk that do not come from cache. You can use this metric to help you 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 is the number of write operations to disk. Write activity is generated even if your application is not active, because Cloud SQL instances write to a system table approximately every second (except for replicas).