This page describes the instance and node specifications for Memorystore for Valkey instances. For instructions on how to create an instance, see Create instances.
Choosing a node type
The nodes in your instance all use the same node type of your choosing. The best node type for your instance depends on your requirements for price, performance, and keyspace capacity.
The standard-small node type lets you provision small instances, and grow your instance by smaller increments at potentially lower costs than other node types. standard-small also offers the advantage of distributing your keyspace across more nodes with a higher total vCPU count. This offers improved price-performance compared to highmem-medium, as long as the total keyspace capacity of the smaller nodes is sufficient for your data needs.
We only recommend choosing the highmem-xlarge node type if you need
more instance capacity than what highmem-medium provides. Although the
highmem-xlarge node type is four times greater than the
highmem-medium type in size, the performance is not four times greater,
as Valkey 7.2 performance does not scale linearly when vCPUs are added to
increasingly larger nodes (scaling up). Instead, to get better price
performance, you should scale out by adding more nodes to an instance.
Node type specification
The node capacity and characteristics depend on which of the four available node 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 instance capacity to help prevent Out Of Memory (OOM) errors. This ensures a smooth experience reading and writing keys. Memory limits and storage details are as follows:
Customizing your storage: While we recommend using the default settings, you have the option to adjust the amount of reserved storage using the
maxmemoryconfiguration. For information aboutmaxmemory, see Supported instance configurations.How much storage do you get? Refer to the previous table's Default writable keyspace capacity column. This shows how much storage is available for your keys by default.
Maximizing storage If you want the maximum possible storage, the total node capacity column shows the storage limit when you set the
maxmemoryconfig to 100%. However, don't recommend choosing amaxmemoryvalue higher than the default setting.The
shared-core-nanonode type has a hard limit of 1.12 GB, and can't be changed with themaxmemoryconfiguration.
Node characteristics
| Node type | vCPU count | SLA offered | Max clients | Max memory for clients (maxmemory-clients configuration) |
|---|---|---|---|---|
| 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% |
Instance specification
This section shows minimum and maximum instance capacities given the instance shape, node type, and replica count.
Minimum writable capacity
Writable capacity is the amount of storage available for writing keys. It is equal 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 minimum writable capacity isn't affected by the number of replicas you choose.
Maximum writable capacity
| Node type and size | Max capacity in Cluster Mode Disabled | Max capacity in Cluster Mode Enabled given instance shape of 250 primary nodes and 0 replicas per node | Max capacity in Cluster Mode Enabled given instance shape of 125 primary nodes and 1 replicas per node | Max capacity in Cluster Mode Enabled given instance shape of 83 primary nodes and 2 replicas per node |
|---|---|---|---|---|
| shared-core-nano - 1.4 GB | 1.12 GB | 350 GB | 175 GB | 116.2 GB |
| standard-small - 6.5 GB | 5.2 GB | 1,625 GB | 812.5 GB | 539.5 GB |
| highmem-medium - 13 GB | 10.4 GB | 3,250 GB | 1,625 GB | 1,079 GB |
| highmem-xlarge - 58 GB | 46.4 GB | 14,500 GB | 7,250 GB | 4,814 GB |
Performance
Using the OSS memtier benchmarking tool in the us-central1 region yielded 120,000 - 130,000 operations per second per 2 vCPU node (standard-small and highmem-medium) with microseconds latency and 1KiB data size.
We recommend that you perform your own benchmarking with real workloads or synthetic workloads that resemble your production traffic. In addition, we recommend that you size your instances with a buffer (or "headroom") for workload spikes or unexpected traffic. For more guidance, see best practices.
Instance endpoints for Cluster Mode Enabled
This section explains the discovery and data endpoints that Cluster Mode Enabled instance has.
Discovery endpoint
Each instance has a discovery endpoint to which your client connects. It is a combination of an IP address and port number. For instructions on how to find your instance's discovery endpoint, see View your instance's discovery endpoint.
Your client also uses it for node discovery. Your client uses the discovery endpoint to retrieve your instance's node topology to bootstrap third-party clients, and keep them updated in steady state. The resulting node topology provides node endpoints (IP and port combinations) to be cached in-memory by your third-party client. Your client then takes care of the updates and redirections automatically with no other application change required. For information on client discovery behavior and best practices, see Client discovery.
The discovery endpoint is highly available because it is backed by multiple nodes across multiple-zones to serve the node topology. Serving topology through the endpoint is robust even when faced with backend node failures or node updates.
Your discovery endpoint has the following behavior:
Your instance's discovery endpoint remains unchanged throughout the lifecycle of the instance, even during maintenance, or by any other action you take such as scaling in or out or changing replica counts.
Node endpoints can change and can be recycled as nodes are added and removed over time. Ideally, you should use a third-party client that can handle these changes automatically through topology refreshes and redirections. Examples of third-party clients can be found at Client library code samples. Your application shouldn't have dependencies or assumptions that node endpoints will remain unchanged for a given instance.
Data endpoint
Each instance also has a Private Service Connect data endpoint that Memorystore for Valkey uses for client connection. Don't connect to this endpoint directly. Instead, Memorystore for Valkey uses this endpoint for connecting your client to nodes in your instance.
Instance endpoints for Cluster Mode Disabled
This section explains the primary and reader endpoints that each Cluster Mode Disabled instance has.
Primary endpoint
The primary endpoint is an IP address to which your application connects. This endpoint directs traffic to the current primary node. Connections to the primary endpoint can send both write and read queries.
Your primary endpoint has the following behavior:
- Your primary endpoint IP address remains unchanged throughout the lifecycle of the instance. If the underlying node fails or undergoes an automatic failover, then Memorystore for Valkey adjusts the IP address automatically. Clients require no changes with the endpoint. However, if unplanned events result in connection failures, then the clients try to re-establish a connection.
- If a primary node becomes the replica, then connections to this replica node end and Memorystore for Valkey redirects new connections to the new primary node through an automatic failover. Clients are expected to retry connections by using exponential backoff.
- If the instance has 1 replica, then the primary endpoint has a higher availability than the reader endpoint. If the instance has 2 replicas provisioned, then both the primary endpoint and reader endpoint have high availability.
Reader endpoint
The reader endpoint is an IP address to which your application connects to. This endpoint 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 the primary node. For applications that require operational access, such as risky scripts and offline jobs, we recommend that you isolate traffic from the primary node by using the reader endpoint.
Your reader endpoint has the following behavior:
- Even when an instance has no read replicas provisioned, Memorystore for Valkey provisions the reader endpoint IP address to allow for the dynamic addition of read replicas.
- If the system has no available read replicas to which to route traffic, a connection to the reader endpoint would be terminated. However, it won't route connections made to the reader endpoint to the primary node.
- If a replica node becomes the primary node, then connections to this primary node end and Memorystore for Valkey redirects new connections to the new replica node. Clients retry these connections by using exponential backoff.
To learn about handling common errors while connecting to Cluster Mode Disabled endpoints see Handling errors in Cluster Mode Disabled.