# Overprovisioned Memorystore Instance Capacity Canonical: https://www.pointfive.co/efficiency-hub/inefficiencies/overprovisioned-memorystore-instance-capacity Memorystore for Redis instances are billed in 1-second increments on their provisioned capacity in GiB, at a rate set by service tier, capacity tier... By: PointFive Updated: 2026-09-28 [Cloud Efficiency Hub](https://www.pointfive.co/efficiency-hub) The short version Memorystore for Redis instances are billed in 1-second increments on their provisioned capacity in GiB, at a rate set by service tier, capacity tier and region. PointFive Research Cloud cost research at PointFive GCP service [GCP Cloud Memorystore](https://www.pointfive.co/efficiency-hub/cloud-services/gcp-cloud-memorystore) Category [Databases](https://www.pointfive.co/efficiency-hub/service-category/databases) Reference CER-0483 Type Overprovisioned Resource ## Explanation Why the waste happens and who it affects. Google's memory management guidance is explicit that instance capacity is the amount of memory you provision and what you are charged for, so an instance holding 4 GiB of keys in a 30 GiB instance pays for all 30 GiB, every second it runs. Oversizing is common because capacity is chosen up front from rough estimates with generous safety margins, copied from production into staging, or set for a data set that later shrank after TTLs, eviction policies or application changes. Standard Tier adds a replica and cross-zone replication on top, which is often unnecessary for non-production caches. Google's memory management guidance recommends right-sizing instances rather than creating over-provisioned ones, and scaling preserves data. Instances with no traffic at all are a separate idle-resource case. ## Billing model The pricing dimensions that drive this cost. Memorystore for Redis charges depend on how the instance is provisioned, not how much memory it uses: Provisioned capacity Billed per GiB-hour in 1-second increments for the full provisioned capacity Capacity tiers Instances fall into tiers M1 to M5 by size; the per-GiB rate is lower in larger tiers, and larger tiers give more network throughput Service tier Basic Tier is a standalone instance; Standard Tier adds automatic cross-zone replication and failover at a higher price, plus optional read replicas Committed use discounts 1-year and 3-year commitments discount the per-GiB rate for M2 and larger tiers; the pricing page lists no CUD rate for M1 ## How to detect 5 checks to find it in your estate. - Compare redis.googleapis.com/stats/memory/usage (used memory) and stats/memory/usage\_ratio with the provisioned capacity over at least 30 days, including peak periods, to find instances whose used memory stays far below capacity - Check stats/memory/system\_memory\_usage\_ratio to confirm there is headroom; Google flags values above 80% as memory pressure, so only instances well below that are downsizing candidates - Review stats/cache\_hit\_ratio and stats/evicted\_keys; a high hit ratio with few or no evictions at low memory usage indicates capacity beyond what the working set needs - Flag Standard Tier instances and instances with read replicas in development, test and staging projects where high availability is not required - Rank instances by Memorystore cost in the Cloud Billing export to focus on the largest ## How to fix 5 ways to remove the waste. - Scale instance capacity down to observed peak usage plus headroom that keeps the system memory usage ratio below 80%; for Standard Tier the new size must be greater than the data currently stored, and Standard Tier reserves 10% of capacity as a replication buffer - Scale during low write traffic and export the data first as Google recommends; scaling preserves data and the IP address but causes a brief connection reset, so clients need retry logic - Compare total cost across capacity tiers, since a smaller instance can drop into a tier with a higher per-GiB rate - For non-production caches that do not need failover, create a Basic Tier instance and migrate with export and import, because Memorystore cannot change an instance between Basic and Standard Tier - Apply committed use discounts only to capacity that remains after rightsizing ## Documentation Vendor references for pricing and configuration. - [Memory management best practices docs.cloud.google.com](https://docs.cloud.google.com/memorystore/docs/redis/memory-management-best-practices) - [Memorystore for Redis pricing cloud.google.com](https://cloud.google.com/memorystore/docs/redis/pricing) - [Scale Redis instances docs.cloud.google.com](https://docs.cloud.google.com/memorystore/docs/redis/scale-instances) - [About scaling instances docs.cloud.google.com](https://docs.cloud.google.com/memorystore/docs/redis/about-scaling-instances) - [Supported monitoring metrics docs.cloud.google.com](https://docs.cloud.google.com/memorystore/docs/redis/supported-monitoring-metrics) - [Redis tier capabilities docs.cloud.google.com](https://docs.cloud.google.com/memorystore/docs/redis/redis-tiers) ## Related inefficiencies [Browse the library](https://www.pointfive.co/efficiency-hub) - GCP Cloud Memorystore CER-0214 ### [Idle Cloud Memorystore Redis Instance](https://www.pointfive.co/efficiency-hub/inefficiencies/idle-cloud-memorystore-redis-instance) Cloud Memorystore instances that remain idle-i.e., not receiving read or write requests-continue to incur full costs based on provisioned size. In test environments, migration scenarios, or deprecated application components, Redis... Databases - GCP Cloud SQL CER-0183 ### [Underutilized Cloud SQL Instance](https://www.pointfive.co/efficiency-hub/inefficiencies/underutilized-cloud-sql-instance) Cloud SQL instances are often over-provisioned or left running despite low utilization. Since billing is based on allocated vCPUs, memory, and storage - not usage - any misalignment between actual workload needs and provisioned capacity... Databases - GCP Cloud SQL CER-0478 ### [Oversized Cloud SQL Storage After Automatic Storage Increase](https://www.pointfive.co/efficiency-hub/inefficiencies/oversized-cloud-sql-storage-after-automatic-storage-increase) Cloud SQL enables automatic storage increase by default. The service checks available storage every 30 seconds and adds capacity when free space drops below a threshold, and by default there is no upper limit. Google documents these... Databases --- Source: the public page above. Product screenshots and illustrative interfaces are examples, not live customer data.