When you create a Cloud SQL instance, you choose
whether it stores data on solid-state drives (SSD) or hard disk drives (HDD):
SSD storage is the most efficient and cost-effective choice for most use
cases.
HDD storage is sometimes appropriate for large datasets (>10 TB) that
are not latency-sensitive or are infrequently accessed.
Regardless of which type of storage you choose, your data is stored on a
distributed, replicated file system that spans across many physical drives.
The guidelines on this page can help you choose between SSD and HDD.
When in doubt, choose SSD storage
There are several reasons why it's best to use SSD storage for your
Cloud SQL instance:
SSD is faster and has more predictable performance than HDD.
HDD throughput is much more limited than SSD throughput.
Individual row reads on HDD are slow. Because of disk seek time, HDD
storage supports only 5% of the read rows per second of SSD storage. Large
multi-row scans, however, are not as adversely impacted.
The cost savings from HDD are minimal, unless you're storing large
amounts of data. Consider
using HDD storage if you're storing at least 10 TB of data.
Use cases for HDD storage
HDD storage is suitable for use cases that meet the following criteria:
You expect to store at least 10 TB of data.
You do not use the data to back a user-facing or latency-sensitive
application.
Your workload falls into one of the following categories:
Batch workloads with scans and writes, and no more than occasional random
reads of a few rows.
Data archival, where you write large amounts of data and rarely read
that data.
For example, if you plan to store extensive historical data for a large number
of remote-sensing devices and then use the data to generate daily reports, the
cost savings for HDD storage might justify the performance tradeoff. On the
other hand, if you plan to use the data to display a real-time dashboard, it
probably would not make sense to use HDD storage—reads would be much more
frequent in this case, and reads are much slower with HDD storage.
Switch between SSD and HDD storage
When you create a Cloud SQL instance, your choice of
SSD or HDD storage for the instance is permanent.
If you need to convert an existing HDD instance to SSD, or conversely,
you can export the data from the existing instance and import
the data into a new instance. Keep in mind that migrating an
entire instance takes time.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-14 UTC."],[],[],null,["# Choose between SSD and HDD storage\n\n\u003cbr /\u003e\n\n[MySQL](/sql/docs/mysql/choosing-ssd-hdd \"View this page for the MySQL database engine\") \\| PostgreSQL \\| [SQL Server](/sql/docs/sqlserver/choosing-ssd-hdd \"View this page for the SQL Server database engine\")\n\n\u003cbr /\u003e\n\nWhen you create a Cloud SQL instance, you choose\nwhether it stores data on solid-state drives (SSD) or hard disk drives (HDD):\n\n- SSD storage is the most efficient and cost-effective choice for most use cases.\n- HDD storage is sometimes appropriate for large datasets (\\\u003e10 TB) that are not latency-sensitive or are infrequently accessed.\n\nRegardless of which type of storage you choose, your data is stored on a\ndistributed, replicated file system that spans across many physical drives.\n\nThe guidelines on this page can help you choose between SSD and HDD.\n\nWhen in doubt, choose SSD storage\n---------------------------------\n\nThere are several reasons why it's best to use SSD storage for your\nCloud SQL instance:\n\n- **SSD is faster and has more predictable performance than HDD.**\n- **HDD throughput is much more limited than SSD throughput.**\n- **Individual row reads on HDD are slow.** Because of disk seek time, HDD storage supports only 5% of the read rows per second of SSD storage. Large multi-row scans, however, are not as adversely impacted.\n- **The cost savings from HDD are minimal, unless you're storing large\n amounts of data.** Consider using HDD storage if you're storing at least 10 TB of data.\n\nUse cases for HDD storage\n-------------------------\n\nHDD storage is suitable for use cases that meet the following criteria:\n\n- You expect to store at least 10 TB of data.\n- You do not use the data to back a user-facing or latency-sensitive application.\n- Your workload falls into one of the following categories:\n\n - Batch workloads with scans and writes, and no more than occasional random reads of a few rows.\n - Data archival, where you write large amounts of data and rarely read that data.\n\nFor example, if you plan to store extensive historical data for a large number\nof remote-sensing devices and then use the data to generate daily reports, the\ncost savings for HDD storage might justify the performance tradeoff. On the\nother hand, if you plan to use the data to display a real-time dashboard, it\nprobably *would not* make sense to use HDD storage---reads would be much more\nfrequent in this case, and reads are much slower with HDD storage.\n\nSwitch between SSD and HDD storage\n----------------------------------\n\nWhen you create a Cloud SQL instance, your choice of\nSSD or HDD storage for the instance is permanent.\n\nIf you need to convert an existing HDD instance to SSD, or conversely,\nyou can [export the data](/sql/docs/postgres/import-export) from the existing instance and [import\nthe data](/sql/docs/postgres/import-export) into a new instance. Keep in mind that migrating an\nentire instance takes time.\n\nWhat's next\n-----------\n\n[Create an instance with SSD or HDD storage](/sql/docs/postgres/create-instance)."]]
