# Scheduling Memorystore for Redis

> Memorystore scheduling scales the replica count down for quiet hours and restores it later. The primary node keeps running, keeps serving and keeps billing all night. Savings equal the removed replicas' node-hours, the cache stays warm with 0 morning rebuild, and overnight failover protection is what gets traded.

Source: https://zop.dev/integrations/gcp/memorystore/schedule
Updated: 2026-08-19

---

## A schedule that never stops the instance

Redis holds state in memory, so powering it off nightly would mean losing or reloading the
dataset every day. The Memorystore schedule does not try: the primary stays up around the
clock, and the lever is the replica count, scaled down in the evening and back up before
business hours. Applications keep reading and writing all night as if nothing happened,
because for the primary, nothing did.

## The saving is counted in replica node-hours

Each read replica is a full node billing the instance's per-GB-hour rate. An instance sized at
10 GB with 2 replicas spends two-thirds of its bill on replica capacity; dropping to zero
replicas overnight halves-plus the nightly cost while leaving the working dataset untouched.
The primary's own node-hours are the floor no Redis schedule can cross.

## What thins out overnight

Replicas are not decorative. With fewer of them, automatic failover has fewer candidates. At
zero, a primary failure at 3am means downtime rather than promotion, and read throughput
concentrates on the primary. Production caches fronting real overnight traffic should keep at
least 1 replica; the aggressive zero-replica window belongs to dev, staging and
internal-tools instances whose 3am availability contract is theoretical.

## No cold cache in the morning

Alone among the data services on this directory, the scheduled resource wakes with its
performance fully intact: the primary never flushed, so the 8am hit rate equals the 7pm hit
rate. Restoring replicas is a background sync from the primary, invisible to clients. The
usual warm-up choreography other schedules require simply does not exist here.

## Timing the restore

Replica re-sync takes time proportional to dataset size. Restore an hour before peak so
failover protection and read capacity are back in place before traffic arrives. The sync is
cheap, but it is not instantaneous.

Keep an eye on primary CPU during the window as well: the reads the replicas were absorbing all
land on a single node overnight.