--- title: "In-memory store: Valkey and Memcached · Frazer" description: "Valkey and Memcached, in the version you pick, run by Frazer next to your databases: Basic, Standard and Cluster modes, a private endpoint in your VPC, ACL users and IAM login, TLS, persistence and backups." url: https://frazer.ai/memory index: https://frazer.ai/llms.txt tokens: 3542 --- > For agents: every page on frazer.ai is indexed at https://frazer.ai/llms.txt. # In-memory store: Valkey and Memcached · Frazer **In-memory store** frazer.ai # Valkey and Memcached, run for you. Pick the engine and the version. Choose the engine and its version: Valkey 8.0 to 9.1 or Memcached 1.6. Then pick a mode: Basic for one node, Standard for a primary with up to five replicas and automatic failover, or Cluster for shards. Your apps keep the clients they use today, over RESP2, RESP3 or the memcached protocol. Frazer runs it next to your databases, behind a private endpoint in your VPC, with ACL users, TLS and backups. On your own servers it is part of the server fee. [Create an instance](https://frazer.ai/start?product=memory) [Read the docs](https://frazer.ai/docs) ``` $ frazer keyvalue instances create cart-cache \ --mode standard --replicas 2 --node-type mem-m1-32 \ --site ovh-vint-hill --network acme-prod-vpc \ --persistence rdb --rdb-period 6h --tls --dry-run Plan + Valkey 9.1 · Standard · 1 primary + 2 replicas + endpoints primary, reader in acme-prod-vpc + ACL user app · password kept in Frazer Secrets + daily backups · kept 7 days · final on delete + 4 default alert policies in Frazer Monitoring Cost included in the server fee ✓ Disruption: none ``` ``` $ frazer keyvalue instances update cart-cache \ --node-type mem-m1-64 --dry-run Plan ~ cart-cache · mem-m1-32 → mem-m1-64 new replicas of the new type sync first, then one graceful failover; old nodes go ! Disruption: failover · connections reset once ``` ``` $ frazer keyvalue instances connect cart-cache --readonly Login iam:lena@acme.example · +@read · expires in 1 h Via Frazer Link · TLS · no public address $ frazer keyvalue instances proxy cart-cache --port 6379 Local localhost:6379 for apps on your laptop ``` ``` $ frazer keyvalue instances import \ --from-rdb frazer://buckets/migr/acme.rdb \ --to acme-jobs --mode standard Check RDB format version · accepted by Valkey 9.1 Plan + acme-jobs · Valkey 9.1 · Standard seeded from the RDB file ``` 01 · Engines and versions ## Two engines, the version you pick. One way to run them. Valkey gets every mode, endpoint, access control, backup and plan; Memcached runs as a pool of cache nodes. Pick the engine at create; the version moves forward by plan. - ### Valkeyrecommended Versions 8.0, 8.1, 9.0 and 9.1. Search (vector and full text), JSON and Bloom filters as switches. Every mode. - ### Memcached Version 1.6. For apps that speak the memcached protocol. A cache: no persistence or backups. New versions arrive within 30 days of their upstream release. Patches apply in your maintenance window; moving to a newer version is a plan you approve, never a downgrade. A version leaves support with 12 months’ notice. 02 · How it works Fig. 1 ## A primary, its replicas, one name. The endpoint follows every failover. In Standard mode your apps write through the primary endpoint and read through the reader. Three monitors you never see watch the primary; when it fails, a replica takes over and Frazer moves the endpoint, so any client works and sees one dropped connection. Backups are taken on a replica and kept in Frazer Storage. **Fig. 1** An instance in Standard mode: endpoints, failover and backups 03 · Three modes ## Three modes, fixed at create. Pick by size and by client. Basic and Standard work with any client. Cluster spreads the keyspace over shards and needs a cluster-aware client. Moving to another mode means a new instance from a backup. Basic, Standard and Cluster modes compared | | Basic | Standard | Cluster | | --- | --- | --- | --- | | Topology | One node | A primary and 1–5 replicas on different servers | 1–64 shards, each with 0–5 replicas | | Client | Any | Any: the primary endpoint follows the primary | A cluster-aware client | | Endpoints | `primary` | `primary` and `reader` | `discovery` on 6379, plus a port per node | | Databases | 16 | 16 | 1, or up to 100 with `cluster-databases` | | Largest | One node type | One node type, up to 102 GiB writable | Shards × node type, up to 64 × 102 GiB | | Failover | None: restart and reload from disk | A quorum of monitors, then the endpoint moves | The cluster bus | | Servers | One is enough | Two or more | Primaries and replicas spread across servers | | For | Dev, staging, previews | Production caches, sessions, queues, rate limits | Large keyspaces, high throughput | ### Sized by memory Each node keeps 80 % of its memory writable; the rest is headroom for forks, replication and client buffers. Shared-CPU types are for Basic only and can power off when idle. A one-server site offers Basic only, and the create page says why. Node types with vCPU, memory and writable memory | Node type | vCPU | Memory | Writable | | --- | --- | --- | --- | | `mem-s1-1` shared CPU | 0.5 | 1.5 GiB | 1.2 GiB | | `mem-s1-3` shared CPU | 1 | 3 GiB | 2.4 GiB | | `mem-m1-8` | 2 | 8 GiB | 6.4 GiB | | `mem-m1-16` | 2 | 16 GiB | 12.8 GiB | | `mem-m1-32` | 4 | 32 GiB | 25.6 GiB | | `mem-m1-64` | 8 | 64 GiB | 51 GiB | | `mem-m1-128` | 16 | 128 GiB | 102 GiB | | `mem-c1-16` high CPU | 8 | 16 GiB | 12.8 GiB | 04 · One page per instance Fig. 2 ## Endpoints, nodes and checks. On one page for each instance. The overview shows the endpoints to copy and how to sign in, every node with its lag, the production checks and what changed lately. Maintenance arrives with a week’s notice and names the disruption it will cause. *The cart-cache instance in the Frazer console: Valkey 9.1.2 in Standard mode, one primary and two replicas on three servers, ready. A banner announces a patch with one failover. Tiles show memory used, hit ratio, operations per second, connections, replication lag and version; below are the primary and reader endpoints to copy with their authentication, the three nodes with lag, eight of eight production checks passing, and recent activity.* **Fig. 2** An instance overview product UI, demo organization ### The production checks - Auth on - TLS on - At least one replica - Persistence on, or cache-only acknowledged - Eviction policy set - Backups OK - Maintenance window set - Under half the keys without a TTL 05 · What survives ## What survives, said plainly. Persistence, backups and failover. An in-memory store is only as durable as you set it up to be. The create page and every plan say what a restart, a failover or a restore keeps. Persistence modes, what survives a restart, and the defaults | Mode | What survives a restart | Default | | --- | --- | --- | | Off | Nothing: a pure cache | The Basic default | | RDB | Data up to the last snapshot, taken every 1, 6, 12 or 24 hours | Standard and Cluster in production: every 6 hours | | AOF | Up to the last second with fsync every second, or every write with always | Opt-in | - Backups daily in your window and on demand, taken on a replica when there is one; kept 1 to 365 days, **7 by default**, with a final backup on delete. - A restore always creates a **new instance**; your app’s endpoint switches after checks. - **No point-in-time recovery.** You get the data since the last snapshot, or the last second with AOF. - Replication is asynchronous, so a failover can lose writes the old primary acknowledged. Use `WAIT` where a write must reach a replica. - A monthly restore drill into a scratch instance compares key counts and shows the result on the page. 06 · Insights Fig. 3 ## See what fills the memory. And which keys run hot. Memory, hit ratio, latency per command and replication come with default alerts. Insights go further: the commands that were slow, and the keys and prefixes that take the space, from a sampled scan that runs on a replica when there is one. *The Insights tab of cart-cache in the Frazer console: the command log of slow commands with duration, client and node; the big keys by memory with type, elements and TTL, three of them without a TTL; and memory by key prefix, led by llm:resp at 41 percent.* **Fig. 3** The Insights tab of an instance product UI, demo organization - ### Command log Slow commands, large requests and large replies every 30 seconds, with arguments masked. - ### Big keys and key prefixes From a sampled scan, on a replica when there is one, daily and on demand: the 50 biggest keys, memory by prefix, keys without a TTL. - ### Data browser Read-only by default, as a short-lived user; edits need write permission and are audited. 07 · What you get ## Everything around the instance. Run by Frazer, changed by plan. - ### ACL users from templates Read-write, read-only and queue-worker rules; rotation keeps two valid passwords, so no downtime. - ### IAM login for people and agents A short-lived user with rules from the role, at most 12 hours, every login audited. - ### TLS on in production A CA per instance; certificates reload without a restart. - ### Resize by plan New replicas of the new type sync, then one graceful failover. Shrinking below your data is refused. - ### Maintenance you can move Seven days’ notice, reschedule up to 14 days, deny periods up to 90 days; staging first. - ### Import and export Create from an RDB file in a bucket; export any backup to your bucket. - ### Tools for agents List, describe, metrics, insights and a read-only scan over MCP; failover and flush wait for a person. - ### Memcached For apps that already speak memcached: 1–20 nodes, a cache only, TLS on. 08 · Controls ## Who may read and write. And what needs a person. ### Who may do what Developer Creates and changes instances through plans that state their disruption. Viewer Reads instances and metrics; never writes data. Responder Reads, and may fail over. Agents Read, scan with previews capped at 1 KiB, and plan. Failover, flush and delete wait for a person. ### What is logged - Every IAM login, with its principal and expiry - Failover and flush, as live actions - Edits and deletes in the data browser - ACL denials, failovers and maintenance, in the instance’s logs ### At the cap - Auth **on by default**; turning it off needs an explicit flag and fails a production check - `KEYS`, `FLUSHALL`, `CONFIG`, `SHUTDOWN` and other admin commands are denied to your users - Flush needs a typed confirmation and, in production, an approval - A spend cap never stops an instance: it pauses fleet compute only. Delete keeps a final backup 09 · Pricing ## Same rates as a VM. Included on your own servers. On your own servers, nodes, replicas and their disks are part of the per-core server fee. Backups count against the Frazer Storage allowance. On the Frazer fleet, nodes bill by the second at the vCPU and memory rates, with no managed premium. [See every price](https://frazer.ai/pricing#lines) Your servers **Included** in the per-core server fee Frazer fleet $0.039 / vCPU-hour + $0.0075 / GiB-hour per node (the fleet's vCPU rate + 30 %) · every copy is a node, except standbys on Shared that serve no reads, at the fleet rates · storage $0.012 / GiB-month per copy · backups up to your storage included A node on the fleet `mem-m1-16` (2 vCPU, 16 GiB): $0.172 per node-hour Backups 100 GB per server included, then $0.012 per GiB-month Powered off Basic only: backups only Network No per-GB fees Questions ## In-memory store, answered. Will my client library work? Yes. Valkey speaks RESP2 and RESP3, so the client libraries your apps use today connect unchanged. Basic and Standard take any client; Cluster mode needs a cluster-aware one. The connect snippets on each instance page show the client for your language. What happens to writes when the primary fails? In Standard mode a quorum of monitors promotes a replica and Frazer moves the primary endpoint to it. Clients see one dropped connection and reconnect to the same name. Replication is asynchronous, so writes the old primary acknowledged can be lost. Use `WAIT` where a write must reach a replica. Basic mode has no failover: the node restarts and reloads from disk. Is there point-in-time recovery? No. With RDB you get the data since the last snapshot; with AOF, up to the last second. Backups restore only into a new instance, and your app’s endpoint switches after checks. Can I change the mode later? No, the mode is fixed at create. To move to Cluster, create a new instance from a backup. Replicas and node type change in place, through a plan that states its disruption. How do I bring an existing cache? Create the instance from an RDB file in a Frazer bucket. Valkey reads files from Valkey and from Redis® Open Source 7.2 or earlier, and the plan checks the format version first. From a newer server, Frazer copies the keys over RESP instead. Or replicate live from the running source over Frazer Access or a VPN, then switch. What about Memcached? Memcached 1.6 is for apps that already speak the memcached protocol: 1 to 20 nodes, a cache only, with no persistence or backups, reachable only through private endpoints with TLS on. For anything new, the create page recommends Valkey Basic with `allkeys-lru`. ## More in Data - [**Databases** Postgres with PITR](https://frazer.ai/databases) - [**Frazer Storage** Objects next to servers](https://frazer.ai/storage) - [**Secrets** Write-only for people](https://frazer.ai/secrets) - [**Volumes and snapshots** NVMe or replicated](https://frazer.ai/volumes) ## Create an instance. Next to your databases, on your servers. [Create an instance](https://frazer.ai/start?product=memory) [Read the docs](https://frazer.ai/docs) Redis is a registered trademark of Redis Ltd. Any rights therein are reserved to Redis Ltd. Any use by Frazer is for referential purposes only and does not indicate any sponsorship, endorsement or affiliation between Redis and Frazer. Valkey includes code that is based on a fork of Redis® Open Source 7.2.