MemoryStore overview
Conversation history lives in sessions, and cross-conversation facts live in the memory bank. Neither one is a MemoryStore instance you create — see use with agents.
This page explains what MemoryStore is, the 30-second mental model, when to use it, and how it stacks up against the equivalent products on GCP, AWS, and Azure.
What it is, in plain words
MemoryStore is a managed in-memory key-value store. "Key-value" means the data model is as simple as it gets: you store a value under a name (the key), and you get it back by that name. "In-memory" means the data lives in RAM rather than on disk. Reads and writes take well under a millisecond, hundreds of times faster than a disk-backed database.
MemoryStore speaks the Redis wire protocol — the exact set of bytes Redis clients send and expect back. Because the bytes match, every Redis client library works unchanged, in Python, Go, JavaScript, or anything else. So does the redis-cli command-line tool. If you know SET, GET, and PING, you already know how to use it.
The 30-second mental model
You create an instance: a private server owned by your project. You pick a name, a size class, an eviction policy (what happens when memory fills up), and whether data survives restarts. The platform provisions it, generates a password, and hands you a connection string. Your workloads connect with any Redis client.
Every instance gets a private DNS name — a hostname that resolves only inside the platform, never on the public internet.
You can also switch on a TLS endpoint at create time. TLS is the encryption that puts the "s" in https, and the Redis version of it uses rediss:// addresses. That endpoint is reachable from the internet, which means the instance's password is the entire boundary in front of your data. That is why the password expires, renews without downtime, and reports every use, and why you can narrow the networks that may reach the address at all with an address allow list. Leave external exposure off unless you need it.
One catch is important enough to state here: port 6379 on the private DNS name is firewalled off from your own agents and services too. Connect from workloads explains who can reach it and what to use instead.
When to use it
- Caching — keep expensive computation or API results close at hand. Use an eviction policy like
allkeys-lruso old entries make room automatically. - Counters and rate limiting — Redis increments are atomic, meaning two clients incrementing at once can never lose a count. That turns "5 requests per user per minute" into a two-command job.
- Queues and coordination — lists plus those same atomic operations give you lightweight work distribution.
- Application session state — shopping carts, login sessions, agent scratch space. Use the default
noevictionpolicy so data is never silently dropped.
Do not make it the only copy of data you cannot recreate. An instance is a single server. There is no failover — no standby copy that takes over if that server fails — and no backups. The honesty box below has the details. Persistence is on by default, but it protects you against a restart, not against deleting the instance or losing the server.
How it compares
The big three all sell a managed Redis-compatible cache. Theirs have more tiers, more choices, and real high-availability options. Ours has one product and one page of settings.
| Crusoe MemoryStore | GCP Memorystore (Redis/Valkey) | AWS ElastiCache / MemoryDB | Azure Cache for Redis / Managed Redis | |
|---|---|---|---|---|
| Client compatibility | Redis wire protocol — any Redis client or redis-cli, unchanged | Redis or Valkey | Valkey / Redis OSS / Memcached; MemoryDB for durable multi-AZ | Redis OSS tiers; Redis Enterprise (Managed Redis) |
| Create-to-connect | One API call; password returned once; connect over the opt-in TLS endpoint | Console/gcloud plus a separate VM to test connectivity | Cluster + VPC security groups + often a test EC2 instance | Portal-driven; product line currently migrating (Cache for Redis is retiring in favor of Managed Redis) |
| Durability | Append-only-file persistence, on by default: with everysec, up to about a second of acknowledged writes can be lost if the machine dies; with always, an acknowledged write is on disk before we acknowledge it — one copy either way, no replica and no backup | RDB snapshots (Standard tier), read replicas | ElastiCache: ephemeral by default; MemoryDB: durable transaction log | Tier-dependent |
| High availability | One instance, no replica and no automatic failover; durability is an append-only file | Standard tier: replicas + automatic failover | Multi-AZ, automatic failover | Replicated tiers available |
| Product choices to make | One product; durability is one setting, changeable after create | Redis vs Valkey, Basic vs Standard vs Cluster | ElastiCache vs MemoryDB (AWS publishes a tiebreaker page) | Cache for Redis vs Managed Redis, five-plus tiers |
Persistence and data safety: MemoryStore instances run with append-only file (AOF) persistence enabled by default, so the data survives a restart of the instance — including the restart a size class or durability change causes. Turn persistence off and there is no disk at all: any restart brings the instance back empty. How much of it survives a machine failure is the durability setting: the default everysec can lose up to about a second of acknowledged writes, and always puts an acknowledged write on disk before we acknowledge it, at a write-latency cost we have not measured. Neither setting is a second copy of your data — there is no replica and no backup. See change the size class or the durability. For external connections, enable the optional TLS endpoint (rediss://) to encrypt traffic in transit.
Instance anatomy at a glance
| Setting | Options | Chosen when |
|---|---|---|
| Size class | small (256Mi container / 192Mi usable), medium (1Gi / 768Mi), large (4Gi / 3Gi) | At create, and changeable afterwards |
| Eviction policy | noeviction (default) plus 7 others like allkeys-lru | At create |
| Persistence | On by default (append-only file, 2Gi disk, sized independently of the size class) | At create; fixed, in either direction |
| Durability | everysec (default) or always, and only while persistence is on | At create, and changeable afterwards |
| External exposure | Off by default; opt-in TLS rediss:// reachable from the internet, password-gated | At create |
The usable memory limit (maxmemory) is set to 75% of the container's memory on purpose. The gap leaves the server room to work, so it is never killed for running the container out of RAM.
The default eviction policy is noeviction. When memory fills up, writes fail loudly instead of quietly discarding data. That is the right default for sessions and queues, and the wrong one for a cache. If you are building a cache, pick allkeys-lru when you create the instance. You cannot change the policy afterward.
Put it on the internet
An instance is reachable from inside your project by default. To give it an address outside, publish an endpoint for it through the API Gateway:
platformctl gateway publish memorystore/cache --allow-cidr 203.0.113.0/24
It is a raw connection, so --auth and --rate-limit are not available — there are no requests to check or count. --allow-cidr is, and the instance's own password is what lets a caller in.
Unpublishing takes the instance off the internet without touching the data, and publishing again brings it back.
See What you can publish.
In this section
- Quickstart — create an instance and run PING/SET/GET in about five minutes.
- Connect from workloads — connection strings, the credential Secret, agents, and the external endpoint.
- Use with agents — connecting MemoryStore instances to agent workflows and managing session state.
- API reference — every endpoint, field, and error.
- Troubleshooting — real error messages and fixes.
- Put it on the internet — publish an endpoint so clients outside your project can connect.