Valkey
Key-value stores run Valkey as an in-memory cache — fast, sized by a compute plan, and empty again after every stop or restart.
A key-value store runs one Valkey server in a resource group and keeps everything it holds in memory. It is a cache: quick to read and write, reachable from the workloads in your boundary, and empty again whenever the server starts.
A cache, not a database
Nothing a store holds is written to disk, and nothing survives the server starting again. The store starts empty after:
- Stop and Start;
- a change of compute plan, and turning Require a password on or off;
- Restart and a password rotation, once the server has actually restarted — see Stop, start and restart;
- the server being moved to another node, for example when its node fails.
There is one server per store — no replicas — and there are no backups or snapshots. Write the applications that use a store so that every key may be missing: fall back to the source of truth, refill the cache as you go, and reconnect when the connection drops. Do not keep the only copy of anything in it.
When the cache is full
A store has a cache size limit: how much data Valkey keeps before it makes room. Unless you set it yourself, the platform derives it from the store's memory limit, leaving a quarter of the memory for the server itself — see Compute plans.
When the limit is reached, the eviction policy decides what happens. The default,
allkeys-lru, removes the key used least recently; noeviction removes nothing and returns errors
on writes instead. Both settings can be changed while the store runs, without emptying it.
A cache size limit at or close to the memory limit leaves the server no room of its own: instead of evicting keys, it runs out of memory, is stopped by the cluster and starts again empty.
Version
Every store runs Valkey 8.0, the image valkey/valkey:8.0-alpine. There is no choice of version;
the API's valkeyVersion field is a label and does not change the image.
Reaching a store
- Inside the boundary. The server listens on port 6379 under an in-cluster name made from the store's name. Workloads in the boundary can connect to it; workloads in other boundaries cannot. See Network isolation.
- The password. On by default: clients must authenticate before they send commands. With Require a password off, any workload that can reach the store can use it.
- From outside the cluster. Only after you turn on External access, which puts a load balancer in front of the server on port 6379, optionally limited to a list of address ranges.
Warning
Traffic to a store is not encrypted, the password included — inside the cluster and through external access alike. Keep external access off unless you need it, and limit it to the networks that need it.
See Connect to a store.
Choosing a data service
| Need | Use |
|---|---|
| A cache, sessions, rate limits, anything that may be lost on a restart | Valkey |
| Relational data and transactions | PostgreSQL or SQL Server |
| Embeddings and similarity search | Qdrant |