MemoryStore overview

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 (a key), and you get it back by that name. "In-memory" means the data lives in RAM, so reads and writes take well under a millisecond — orders of magnitude faster than a disk-backed database.

Under the hood each instance runs Valkey, which speaks the Redis wire protocol. That means every Redis client library — in Python, Go, JavaScript, anything — and the redis-cli command-line tool work unchanged. 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, single-node 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.

Each instance is reachable from your project's workloads by a private DNS name. Optionally, you can expose it on a TLS rediss:// endpoint reachable from your Crusoe VPC — never from the public internet. There is no public endpoint, full stop; that's a security posture, not a missing feature.

When to use it

• Caching — keep expensive computation or API results hot. Use an eviction policy like allkeys-lru so old entries make room automatically.
• Counters and rate limiting — atomic increments make "5 requests per user per minute" a two-command job.
• Queues and coordination — lists and atomic operations for lightweight work distribution.
• Application session state — shopping carts, login sessions, agent scratch space. Use the default noeviction policy so data is never silently dropped.

Don't use it as your system of record for data you can't recreate: an instance is a single node with no failover and no backups (see the honesty box below). Persistence (on by default) protects against restarts, not against deletion or node loss.

How it compares

	Crusoe MemoryStore	GCP Memorystore (Redis/Valkey)	AWS ElastiCache / MemoryDB	Azure Cache for Redis / Managed Redis
Engine	Valkey, Redis wire-compatible	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 from your workloads	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	Optional AOF persistence (~1 s loss window), on by default	RDB snapshots (Standard tier), read replicas	ElastiCache: ephemeral by default; MemoryDB: durable transaction log	Tier-dependent
High availability	None — single node (alpha)	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

Honest limits: every MemoryStore instance is a single node. No replication, no automatic failover, no automatic backups. If the node dies, persistence replays writes up to about a second before the failure; if you delete the instance, the data volume is destroyed irreversibly. In-cluster traffic is plaintext redis:// inside the platform; TLS is available only on the optional VPC-scoped endpoint. The big clouds all offer HA tiers today — if you need failover guarantees right now, that's them, not us.

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 your Crusoe VPC only	At create

The usable memory limit (maxmemory) is deliberately set to 75% of the container's memory so the server itself never gets killed for running out of RAM.

The one decision that bites people

The default eviction policy is noeviction: when memory is full, writes fail loudly instead of silently discarding data. That's the right default for sessions and queues, and the wrong one for a cache. If you're building a cache, pick allkeys-lru at create time — the policy is not editable afterward.

What's 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 VPC endpoint.
• Use with agents — where agent sessions actually live, and the shared-store alpha caveat.
• API reference — every endpoint, field, and error.