MemoryStore overview

Looking for agent memory?

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-lru so 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 noeviction policy 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, about 1 s of possible loss; on by default	RDB snapshots (Standard tier), read replicas	ElastiCache: ephemeral by default; MemoryDB: durable transaction log	Tier-dependent
High availability	Single-node instance with AOF persistence	Standard tier: replicas + automatic failover	Multi-AZ, automatic failover	Replicated tiers available
Product choices to make	One product; durability is a checkbox	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 automated append-only file (AOF) persistence enabled by default. Writes are committed continuously, preserving your data across service restarts. 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; fixed
Eviction policy	noeviction (default) plus 7 others like allkeys-lru	At create
Persistence	On by default (append-only file, 2Gi volume)	At create; fixed
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 one decision that bites people

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.

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.