This page describes the instance and node specifications for Memorystore for Valkeyinstances. For instructions on how to create an instance, seeCreate instances.

Choose a node type

The nodes in your instance all use the same node type of your choosing. The bestnode type for your instance depends on your requirements for price, performance,and keyspace capacity.

Theshared-core-nano node type is for small workloads. This node type providesvariableperformanceand doesn't have an SLA, making it unsuitable for production workloads.

Thestandard-small node type lets you provision small instances, and grow yourinstance by smaller increments at potentially lower costs than other node types.standard-small also offers the advantage of distributing your keyspace acrossmore nodes with a higher total vCPU count. This offers improved priceperformance compared tohighmem-medium, as long as the total keyspace capacityof the smaller nodes is sufficient for your data needs.

We only recommend choosing thehighmem-xlarge node type if you needmore instance capacity than whathighmem-medium provides. Although thehighmem-xlarge node type is four times greater than thehighmem-medium type in size, the performance is not four times greater,as Valkey 7.2 performance does not scale linearly when vCPUs are added toincreasingly larger nodes (scaling up). Instead, to get better priceperformance, you should scale out by adding more nodes to an instance.

Caution: We recommend that you use theshared-core-nano node type for development or testing purposesonly because this node type has no SLA. If you run Memorystore for Valkey in aproduction environment, then we recommend using thestandard-small,highmem-medium, orhighmem-xlarge node types.

Node type specification

The node capacity and characteristics depend on which of the four availablenode types you choose:

Keyspace capacity and reserved overhead

Node type	Default writable keyspace capacity	Total node capacity
shared-core-nano	1.12 GB	1.4 GB
standard-small	5.2 GB	6.5 GB
highmem-medium	10.4 GB	13 GB
highmem-xlarge	46.4 GB	58 GB

Memorystore automatically sets aside a portion of your instancecapacity to help prevent Out Of Memory (OOM) errors. This ensures a smoothexperience reading and writing keys. Memory limits and storage details are asfollows:

• Customizing your storage: While we recommend using the default settings,you have the option to adjust the amount of reserved storage using themaxmemory configuration. For information aboutmaxmemory,seeSupported instance configurations.

• How much storage do you get? Refer to the previous table'sDefault writable keyspace capacity column. This shows how much storage isavailable for your keys by default.

• Maximizing storage If you want the maximum possible storage, thetotal node capacity column shows the storage limit when you set themaxmemory config to 100%. However, don't recommend choosing amaxmemoryvalue higher than the default setting.

• Theshared-core-nano node type has a hard limit of 1.12 GB, and can'tbe changed with themaxmemory configuration.

Node characteristics

Node type	vCPU count	SLA offered	Max clients	Max memory for clients (maxmemory-clientsconfiguration)
shared-core-nano	0.5	No	5,000	12%
standard-small	2	Yes	16,000 (default). Max value is 32,000	7%
highmem-medium	2	Yes	32,000 (default). Max value is 64,000	7%
highmem-xlarge	8	Yes	64,000	4%

The more virtual CPUs (vCPUs) that you select for your instance, the better theperformance. If your instance runs resource-intensive workloads, then select anode type with a higher vCPU (for example,highmem-xlarge). If your instanceperforms less-demanding tasks, then select a node type with a lower vCPU (forexample,highmem-medium).

Scale an instance

As part of creating a Memorystore for Valkey instance, you choose anode type for the instance and specify the number of shards for the instance.After you create the instance, and as the capacity needs for your instancechange, you might need to scale the instance in the following ways:

• Change the number of shards for your instance. This ishorizontal scaling.You scale an instance horizontally by performing one of the following actions:
  • Add shards to the instance. This is scaling the instanceout.
  • Remove shards from the instance. This is scaling the instancein.
• Change the node type for your instance. This isvertical scaling. To scalean instance vertically, change the node type of the instance to one of thefollowing node types:
  • Change to a larger node type. This is scaling the instanceup.
  • Change to a smaller node type. This is scaling the instancedown.

Note: For more information about horizontal andvertical scaling, seeAbout scaling instance capacity. For moreinformation about changing the capacity of your instance by scaling the nodetype or the shard count, seeScale instance capacity.

Instance specification

This section shows minimum and maximum instance capacities given the instanceshape, node type, and replica count.

Minimum writable capacity

Writable capacity is the amount of storage available for writing keys. It isequal to the size of one instance node. Therefore, depending on the node type,the minimum writable capacity is 1.4 GB, 6.5 GB, 13 GB, or 58 GB. The minimumwritable capacity isn't affected by the number of replicas you choose.

Maximum writable capacity

This section lists the maximum writable capacity for Cluster Mode Enabled andCluster Mode Disabled instances.

Cluster Mode Enabled instances

The following table lists the maximum writable capacity for Cluster Mode Enabledinstances that have 0-5 replicas per node.

Node type and size	Maximum capacity, given an instance shape of 250 primary nodes and 0 replicas per node	Maximum capacity, given an instance shape of 125 primary nodes and 1 replica per node	Maximum capacity, given an instance shape of 83 primary nodes and 2 replicas per node	Maximum capacity, given an instance shape of 62 primary nodes and 3 replicas per node	Maximum capacity, given an instance shape of 50 primary nodes and 4 replicas per node	Maximum capacity, given an instance shape of 41 primary nodes and 5 replicas per node
shared-core-nano - 1.4 GB	350 GB	175 GB	116.2 GB	86.8 GB	70 GB	57.4 GB
standard-small - 6.5 GB	1,625 GB	812.5 GB	539.5 GB	403 GB	325 GB	266.5 GB
highmem-medium - 13 GB	3,250 GB	1,625 GB	1,079 GB	806 GB	650 GB	533 GB
highmem-xlarge - 58 GB	14,500 GB	7,250 GB	4,814 GB	3,596 GB	2,900 GB	2,378 GB

Cluster Mode Disabled instances

The following table lists the maximum writable capacity for Cluster ModeDisabled instances.

Node type and size	Maximum capacity
shared-core-nano - 1.4 GB	1.12 GB
standard-small - 6.5 GB	5.2 GB
highmem-medium - 13 GB	10.4 GB
highmem-xlarge - 58 GB	46.4 GB

Performance

Using theOSS memtier benchmarking tool in theus-central1 region yielded 120,000 - 130,000operations per second per 2 vCPU node (standard-small andhighmem-medium)with microseconds latency and 1KiB data size.

We recommend that you perform your own benchmarking with real workloads orsynthetic workloads that resemble your production traffic. In addition, werecommend that you size your instances with a buffer (or "headroom") forworkload spikes or unexpected traffic. For more guidance, seebest practices.

Instance endpoints for Cluster Mode Enabled

This section explains the discovery and data endpoints that Cluster Mode Enabledinstance has.

Discovery endpoint

Each instance has a discovery endpoint to which your client connects. It isa combination of an IP address and port number. For instructions on how tofind your instance's discovery endpoint, seeView your instance's discovery endpoint.

Your client also uses it for node discovery. Your client uses the discoveryendpoint to retrieve your instance's node topology to bootstrap third-partyclients, and keep them updated in steady state. The resulting node topologyprovides node endpoints (IP and port combinations) to be cached in-memory byyour third-party client. Your client then takes care of the updates andredirections automatically with no other application change required. Forinformation on client discovery behavior and best practices, seeClient discovery.

The discovery endpoint is highly available because it is backed by multiplenodes across multiple-zones to serve the node topology. Serving topology throughthe endpoint is robust even when faced with backend node failures or nodeupdates.

Your discovery endpoint has the following behavior:

1. Your instance's discovery endpoint remains unchanged throughout thelifecycle of the instance, even during maintenance, or by any other action youtake such as scaling in or out or changing replica counts.

2. Node endpoints can change and can be recycled as nodes are added and removedover time. Ideally, you should use a third-party client that can handle thesechanges automatically through topology refreshes and redirections. Examples ofthird-party clients can be found atClient library code samples. Your application shouldn't have dependencies orassumptions that node endpoints will remain unchanged for a given instance.

Data endpoint

In addition to the discovery endpoint, each Cluster Mode Enabled instance has adata endpoint. This endpoint is reserved for Memorystore for Valkey to use toconnect your client to nodes in the instance. Therefore, don't connect to thisendpoint directly.

Instance endpoints for Cluster Mode Disabled

This section explains the primary and reader endpoints that each Cluster ModeDisabled instance has.

Primary endpoint

The primary endpoint is an IP address to which your application connects. Thisendpoint directs traffic to the current primary node. Connections to the primaryendpoint can send both write and read queries.

Your primary endpoint has the following behavior:

1. Your primary endpoint IP address remains unchanged throughout the lifecycleof the instance. If the underlying node fails or undergoes an automaticfailover, then Memorystore for Valkey adjusts the IP address automatically.Clients require no changes with the endpoint. However, if unplanned eventsresult in connection failures, then the clients try to re-establish aconnection.
2. If a primary node becomes the replica, then connections to this replica nodeend and Memorystore for Valkey redirects new connections to the new primary nodethrough an automatic failover. Clients are expected to retry connections byusingexponential backoff.
3. If the instance has 1 replica, then the primary endpoint has a higheravailability than the reader endpoint. If the instance has 2 replicasprovisioned, then both the primary endpoint and reader endpoint have highavailability.

Reader endpoint

The reader endpoint is an IP address to which your application connects. Thisendpoint load balances connections across the replicas in the instance evenly.Connections to the read replica can send read queries, but not write queries.The reader endpoint increases throughput and provides traffic isolation from theprimary node. For applications that require operational access, such as riskyscripts and offline jobs, we recommend that you isolate traffic from the primarynode by using the reader endpoint.

Note: Memorystore for Valkey maintains read replicas by using asynchronousreplication. If applications require "read your write" consistency, thenquerying from read replicas can return inconsistent data because the replica canlag by a few seconds. However, if you require "read your write" consistency,then query using the primary endpoint. Even in this case it is possible to havestale reads after a failover.

Your reader endpoint has the following behavior:

1. Even when an instance has no read replicas provisioned, Memorystore for Valkeyprovisions the reader endpoint IP address to allow for the dynamic addition ofread replicas.
2. If the system has no available read replicas to which to route traffic, aconnection to the reader endpoint would be terminated. However, it won't routeconnections made to the reader endpoint to the primary node.
3. If a replica node becomes the primary node, then connections to this primarynode end and Memorystore for Valkey redirects new connections to the new replica node.Clients retry these connections by usingexponential backoff.

To learn about handling common errors while connecting to Cluster Mode Disabledendpoints seeHandling errors in Cluster Mode Disabled.