[Yandex Cloud documentation](../../index.md) > [Yandex Managed Service for PostgreSQL](../index.md) > [Concepts](index.md) > Storage in Managed Service for PostgreSQL # Storage in Managed Service for PostgreSQL Managed Service for PostgreSQL allows you to use network and local storage drives for database clusters. Network drives are based on network blocks, i.e., virtual drives in the Yandex Cloud infrastructure. Local drives are physically located on the database host servers. When creating a cluster, you can select the following disk types for data storage: * **Network HDDs** (`network-hdd`): Most cost-effective option for clusters with low requirements for read and write performance. * **Network SSDs** (`network-ssd`): Compromise solution: slower than local SSDs, network SSDs ensure data integrity in the event of Yandex Cloud hardware failure. * **Non-replicated SSDs** (`network-ssd-nonreplicated`): Network disks with higher performance achieved by eliminating redundancy. You can only increase the size of these disks in 93 GB increments. * **Ultra high-speed network SSDs with three replicas** (`network-ssd-io-m3`): Network disks that deliver performance equivalent to non-replicated SSDs while ensuring redundancy. You can only increase the size of these disks in 93 GB increments. * **Local SSDs** (`local-ssd`): Highest-performing disks. You can expand such a storage as follows: * For **Intel Broadwell** and **Intel Cascade Lake**: Only in 100 GB increments. * For **Intel Ice Lake** and **AMD Zen 4**: Only in 368 GB increments. For clusters with hosts residing in the `ru-central1-d` [availability zone](../../overview/concepts/geo-scope.md), local SSD storage is not available if using Intel Cascade Lake. [Block](https://en.wikipedia.org/wiki/Block_(data_storage)) size for all disk types is 4 KB. {% note info %} Up to 5% of disk space is reserved for system use, so the disks may have less available space than indicated when creating a cluster. For more information about sizes and performance of different disk types, see [this Yandex Compute Cloud guide](../../compute/concepts/limits.md#compute-limits-disks). {% endnote %} ## Selecting disk type when creating a cluster {#storage-type-selection} The number of hosts you can create together with a PostgreSQL cluster depends on the selected disk type: * You can create a cluster only with three or more hosts when using the following disk types: * Local SSDs (`local-ssd`) * Non-replicated SSDs (`network-ssd-nonreplicated`) Storage on local SSDs increases your cluster costs: you pay for the cluster even if it is stopped. For more information, see [Pricing policy](../pricing.md). {% note info %} Local SSDs may slightly increase the load on the CPU cores of cluster hosts. {% endnote %} * You can add any number of hosts within the current quota when using the following disk types: * Network HDDs (`network-hdd`) * Network SSDs (`network-ssd`) * Ultra high-speed network SSDs with three replicas (`network-ssd-io-m3`) For more information about limits on the number of hosts per cluster, see [Quotas and limits](limits.md). ## Disk encryption {#disk-encryption} When creating or restoring a cluster from a backup, you can encrypt the storage disk with a [custom KMS key](../../kms/concepts/key.md). To encrypt a disk of an already created cluster, disable encryption, or encrypt a disk with a different key, create a backup of the cluster and restore it with the new settings. To create an encrypted disk, you need the `kms.keys.user` [role](../../kms/security/index.md#kms-keys-user) or higher. If you deactivate the key used to encrypt a disk, access to the data will be suspended until you reactivate the key. {% note alert %} If you delete the key used to encrypt a disk or its [version](../../kms/concepts/version.md), you will irrevocably lose access to your data. For more information, see [this Key Management Service guide](../../kms/concepts/version.md#version-distruct). {% endnote %} ## Managing disk space {#manage-storage-space} When the storage is more than 97% full, Managed Service for PostgreSQL automatically switches the host to `read-only` mode. All DBs get the `DEFAULT_TRANSACTION_READ_ONLY = TRUE` setting through the `ALTER DATABASE` query. In this mode, the `INSERT`, `DELETE`, or `UPDATE` queries result in an error. You can monitor storage utilization on cluster hosts [by setting up alerts in Yandex Monitoring](../operations/storage-space.md#set-alert): ### Recovering a cluster from read-only mode {#read-only-solutions} Use one of these methods: * [Increase the storage capacity](../operations/storage-space.md#change-disk-size) to exceed the threshold value. Managed Service for PostgreSQL will then disable read-only mode automatically. * [Disable read-only mode manually](../operations/storage-space.md#read-only-solutions) and free up storage space by deleting some data. {% note alert %} When doing so, make sure the amount of free disk space never reaches zero. Otherwise, with the fail-safe mechanism disabled, PostgreSQL will crash, rendering the cluster inoperable. {% endnote %} ### Automatic storage expansion {#auto-rescale} Automatic storage expansion prevents situations where the disk runs out of free space and hosts go read-only. The storage size increases upon reaching the specified threshold percentage of the total capacity. There are two thresholds: * Scheduled expansion threshold: To schedule such an expansion, an algorithm analyzes data from the last few hours and estimates how quickly the storage is filling up. If the calculations show that the threshold will be exceeded by the start of the nearest [maintenance window](maintenance.md#maintenance-window), the system schedules a storage expansion. If a check at the maintenance start shows that the threshold was indeed exceeded, the storage size is increased. * Immediate expansion threshold: When reached, the storage size increases immediately. You can use either one or both thresholds. If you set both, make sure the immediate increase threshold is higher than the scheduled one. Upon reaching the specified threshold, the storage expands differently depending on the disk type: * For network HDDs and SSDs, by the higher of the two values: 20 GB or 20% of the current disk size. * For non-replicated SSDs and ultra high-speed network SSDs with three replicas, by 93 GB. * For local SSDs: * In an **Intel Broadwell** or **Intel Cascade Lake** cluster, by 100 GB. * In an **Intel Ice Lake** or **AMD Zen 4** cluster, by 368 GB. If the threshold is reached again, the storage will be automatically expanded until it reaches the specified maximum. After that, you can set a new maximum storage size manually. You can configure automatic storage expansion when [creating](../operations/cluster-create.md) or [updating a cluster](../operations/storage-space.md#disk-size-autoscale). If you set the scheduled increase threshold, you also need to configure the maintenance window schedule. When you change the storage size, the cluster hosts are updated one at a time in random order. If you need to restart a host during an update, it will become unavailable for this time period. Prior to the master host's update, one of the replicas takes over its role. If you access a cluster using the [FQDN of the master host](../operations/connect/fqdn.md), the cluster may become unavailable. To ensure uninterrupted operation of your application, list all the cluster hosts and specify `target_session_attrs=primary` when connecting, or connect via a [special FQDN](../operations/connect/fqdn.md) always pointing to the current master host. {% note warning %} You cannot reduce the storage size following an automatic expansion. {% endnote %} ## Use cases {#examples} * [Writing data from a device into a database](../tutorials/data-recording.md) * [Writing load balancer logs to PostgreSQL](../tutorials/logging.md) * [Creating an MLFlow server for logging experiments and artifacts](../tutorials/mlflow-datasphere.md) * [Monitoring the status of geographically distributed devices](../tutorials/datalens.md)