--- title: "In-memory store" description: "Valkey or Memcached in the version you pick, in Basic, Standard or Cluster mode, run by Frazer next to your databases, behind a private endpoint in your VPC, with ACL users, TLS and backups." url: https://frazer.ai/docs/memory index: https://frazer.ai/docs/llms.txt tokens: 5071 --- > For agents: this page is indexed at https://frazer.ai/docs/llms.txt, and every page at https://frazer.ai/llms.txt. Copy commands from this file exactly. # In-memory store The In-memory store runs Valkey or Memcached for your caches, sessions, queues and rate limits, in the version you pick. Frazer runs it in the same data cluster as your [databases](https://frazer.ai/docs/databases), on your servers or the Frazer fleet, behind a private endpoint in your VPC. Pick one of three modes, and every change shows its disruption before you apply it, including what a failover can lose. Product overview: [In-memory store](https://frazer.ai/memory). ## How it works You pick the engine and its version at create: | Engine | Versions | Modes | Notes | | --- | --- | --- | --- | | Valkey (default) | 8.0, 8.1, 9.0, 9.1 | Basic, Standard, Cluster | Search (vector and full text), JSON and Bloom filters as switches | | Memcached | 1.6 | A pool of nodes | For apps that speak the memcached protocol; a cache with no persistence or backups ([Memcached](#memcached)) | Valkey speaks RESP2 and RESP3, so the client libraries your apps use today connect unchanged. New versions arrive within 30 days of their upstream release, patches apply in your maintenance window, and moving to a newer version is a plan you approve, never a downgrade. An instance runs on the `db-memory` node pool of the data cluster Frazer operates for your server pool. A primary and its replicas always sit on different servers. Apps reach the instance through private endpoints, never through a node’s own address, so the endpoint follows every failover and any client works. - **Instance**: one engine deployment with a mode, a node type, an endpoint, persistence, backups and a maintenance window. - **Mode**: Basic, Standard or Cluster. The mode is fixed at create. - **Node type**: the memory size of each node. The engine’s `maxmemory` is 80 % of node memory; the rest is headroom for forks, replication and client buffers. - **Endpoint**: `primary` (read-write), `reader` (across replicas) or `discovery` (Cluster mode). - **ACL user**: a user with rules from a template; apps get the password from [Secrets](https://frazer.ai/docs/secrets). | Property | Basic | Standard | Cluster | | --- | --- | --- | --- | | Topology | One node | A primary and 1 to 5 replicas on different servers | 1 to 64 shards, each with 0 to 5 replicas | | Client | Any | Any | 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` | | Failover | None: the node restarts and reloads 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 | Development, staging, previews | Production caches, sessions, queues, rate limits | Large keyspaces, high throughput | In Standard mode three hidden monitors watch the primary. When it fails, a replica takes over and Frazer moves the `primary` endpoint to it; clients see one dropped connection and reconnect to the same name. Replication is asynchronous, so a failover can lose writes the old primary acknowledged. Use `WAIT` where a write must reach a replica. | Node type | vCPU | Memory | Writable | | --- | --- | --- | --- | | `mem-s1-1` (shared CPU, Basic only) | 0.5 | 1.5 GiB | 1.2 GiB | | `mem-s1-3` (shared CPU, Basic only) | 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 | ## Create an instance Pick a mode and a node type first. Standard needs two servers in the pool; a one-server site offers Basic only, and the create page says why. ### CLI 1. Plan the instance. The plan changes nothing. ```sh 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 ``` ```text title="Output" 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 ``` 2. Apply it: run the same command without `--dry-run`. 3. Check the instance and its endpoints. ```sh frazer keyvalue instances describe cart-cache ``` ### Console 1. Open **Data › In-memory** and choose **Create instance**. 2. **Basics**: the name, with a preview of its DNS name, and an engine card. Valkey is recommended. 3. **Shape**: a mode card, a node type, replicas and shards, and the site with live capacity. 4. **Data and access**: persistence, backups, auth, TLS, network and subnet, eviction policy, maintenance window and deletion protection. 5. Check the right rail: the monthly estimate, the quota and warnings such as auth off or persistence off in production. **Copy as CLI / API / YAML** gives you the same request. Choose **Plan**, then **Create**. The instance’s **Overview** has a connect card with the endpoints and snippets for the command-line client, Go, Python, Node and Java, and production checks that show what still needs attention. A serverless stack can create an instance too and bind it to a service as `VALKEY_URL` (alias `REDIS_URL`), or `MEMCACHED_SERVERS` for Memcached. See [Serverless](https://frazer.ai/docs/serverless). ## Connect Endpoints get private DNS names in your project, for example: | Endpoint | Name | | --- | --- | | `primary` | `cart-cache.mem.acme-production.internal:6379` | | `reader` | `cart-cache-ro.mem.acme-production.internal:6379` | | `discovery` (Cluster) | Port 6379; node `n` answers on port `11000+n` under its own hostname | Create a user for each app from a template. The password goes into Frazer Secrets and reaches your workloads through the cluster’s secret sync; nobody reads it back. ```sh frazer keyvalue users create app --instance cart-cache --template app-readwrite ``` | Template | Rules | | --- | --- | | `app-readwrite` | `+@all -@admin -@dangerous ~*` | | `app-readonly` | `+@read ~*` | | `queue-worker` | Rules for a queue consumer | | Custom | Your own ACL rules | People and agents connect with their Frazer identity instead of a password: ```sh frazer keyvalue instances connect cart-cache --readonly frazer keyvalue instances proxy cart-cache --port 6379 ``` ```text title="Output" Login iam:lena@acme.example · +@read · expires in 1 h Via Frazer Link · TLS · no public address ``` `connect` asks for a short-lived ACL user with rules from your role (`keyvalue.instances.readData` gives `+@read`). It lasts at most 12 hours and is deleted at expiry, which closes its connections. `proxy` serves the instance on `localhost:6379` for apps on your laptop. - **TLS** is on by default in production projects, with a CA per instance. Download the CA bundle from **Access**. Certificates reload without a restart. - **The `default` user** is disabled while auth is on. Turning auth off needs an explicit flag and fails a production check. - **Blocked commands**: `KEYS`, `FLUSHALL`, `FLUSHDB`, `DEBUG`, `CONFIG`, `MODULE`, `SHUTDOWN`, `REPLICAOF`, and cluster and ACL writes are denied to your users. Change settings through Frazer instead: `maxmemory-policy`, `maxclients`, `notify-keyspace-events` and `timeout` are on an allowlist per version. - **Modules**: search, JSON and Bloom filters can be switched on per instance. ## Persistence and backups | Persistence | What survives a restart | Default | | --- | --- | --- | | Off | Nothing: a pure cache | Basic | | 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 `everysec`, or every write with `always` | Opt-in | Changing the persistence mode can need maintenance, and the plan says so. The disk is local NVMe at twice the node’s memory; it is fixed at create and can only grow. Backups run daily in your window and on demand. They are taken on a replica when there is one (on Basic, on the node itself, with a latency warning) and kept in Frazer Storage for 1 to 365 days, 7 by default. Delete takes a final backup, and backups outlive the instance. ```sh frazer keyvalue backups list cart-cache frazer keyvalue backups create cart-cache # Restore always creates a new instance frazer keyvalue instances restore --to cart-cache-r ``` > **Caution:** > > There is no point-in-time recovery. You get the data since the last snapshot, or up to the last second with AOF. A monthly restore drill restores each instance into a scratch instance, compares key counts and shows the result on the instance page. `frazer recovery drills list --json` lists the drills with their measured results. ### Bring an existing cache Create an instance from an RDB file in a Frazer [bucket](https://frazer.ai/docs/storage). Valkey reads files from Valkey and from Redis® Open Source 7.2 or earlier; the plan checks the file’s format version first, because files from newer versions are refused. From a newer Redis® server, Frazer copies the keys over RESP instead and lists any key types Valkey does not have. To take data out, export any backup to your bucket. ```sh frazer keyvalue instances import --from-rdb frazer://buckets/migr/acme.rdb \ --to acme-jobs --mode standard ``` ## Scale and fail over | Change | Method | Disruption | | --- | --- | --- | | Replicas, 1 to 5 | A new replica syncs from the primary | None; a short memory spike on the primary | | Node type, Standard or Cluster | New replicas of the new type sync, then one graceful failover; old nodes are removed | Failover: connections reset once | | Node type, Basic | A new node reloads from RDB or AOF | Downtime; all data is lost if persistence is off, and the plan shows it in red | | Shards, Cluster | Slots move to new shards with atomic slot migration | None to rolling | ```sh frazer keyvalue instances update cart-cache --node-type mem-m1-64 --dry-run ``` ```text title="Output" 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 ``` A plan that shrinks a node type below your data is refused. The mode cannot change: to move to Cluster mode, create a new instance from a backup. When memory stays above 80 % for an hour, Frazer suggests a resize as a plan; it applies one on its own only under a policy you opt into. To fail over by hand, for example to test your clients: ```sh frazer keyvalue instances failover cart-cache --graceful ``` ### Maintenance Patches install automatically in your maintenance window: replicas first, a new node before an old one is removed, and one coordinated failover per shard. You get seven days’ notice, and you can reschedule by up to 14 days, apply now, or set deny periods of up to 90 days. Staging projects go first and production a week later. A new minor version is opt-in for six months, then automatic. Basic instances state the restart’s downtime in every notice. Before a version leaves support you get 12 months’ notice. ## Monitor Metrics go to your project’s [Frazer Monitoring](https://frazer.ai/docs/monitoring) tenant and logs to its log store: server, failover monitor and failover events, `ACL LOG` denials and maintenance. The default alerts are created in Frazer Monitoring, where you can edit them. | Group | Default alert | | --- | --- | | Capacity | Memory above 85 % for 15 minutes | | Cache efficiency | Evictions with `noeviction` (OOM errors); hit ratio 20 points below its 7-day baseline | | Latency and CPU | p99 above 5 ms for 10 minutes; main thread above 90 % | | Clients | Any rejected connection | | Replication | Lag above 10 seconds; any failover, as information | | Persistence | The last save failed | | Cluster | One shard more than twice as busy as another | **Insights** show what the charts cannot: - **Command log**: slow commands, large requests and large replies, read every 30 seconds with arguments masked. - **Big keys**: the top 50 by memory and elements, from a sampled scan on a replica, daily and on demand. - **Hot keys**: exact hot keys need an LFU eviction policy; otherwise you see hot slots. - **Key prefixes** and **TTL health**: memory by prefix, and the share of keys without a TTL. The **Data** tab has a read-only browser and a console. Both run as a short-lived IAM user; edits and deletes need `keyvalue.instances.writeData`, are audited, and need confirmation in production. ## Memcached Choose the Memcached engine card on the create page when an app already speaks the memcached protocol. For anything new, the create page recommends Valkey Basic with `allkeys-lru`. - 1 to 20 nodes of one node type, with no replicas and no failover. - Clients shard across the nodes themselves; a discovery endpoint returns the current node addresses. - A cache only: no persistence, no backups, no restore. A node restart empties that node. - memcached has no per-user auth, so instances are reachable only through private endpoints, with TLS on. IAM login does not apply. - Adding or removing nodes is a plan that warns that keys on moved nodes become cache misses. ## Access and audit | Who | What they can do | | --- | --- | | Developer | Create and change instances through plans | | Viewer | Read instances and metrics; never writes data | | Responder | Read, and fail over | | Agents | Read, scan with previews capped at 1 KiB, and plan; failover, flush and delete wait for a person | - Permissions: `keyvalue.instances.create`, `get`, `list`, `update`, `delete`, `connect`, `failover`, `flush`, `readData` and `writeData`, plus `keyvalue.backups.create`, `restore` and `export`. - Every IAM login is audited with its principal and expiry. Failover and flush are audited live actions. - Flush needs a typed confirmation and, in production, an approval. - Production checks on each instance: auth on, TLS on, at least one replica, persistence on or cache-only acknowledged, an eviction policy set, backups OK, a maintenance window set, and fewer than half the keys without a TTL. - A spend cap never stops an instance on your own servers. ## Limits and quotas | Item | Default | | --- | --- | | Replicas, Standard | 1 to 5 | | Shards, Cluster | 1 to 64, each with 0 to 5 replicas | | Writable memory | 80 % of node memory; up to 102 GiB per node | | Databases | 16 in Basic and Standard; 1 in Cluster, up to 100 with `cluster-databases` | | Backup retention | 1 to 365 days, 7 by default | | IAM login | At most 12 hours | | Memcached | 1 to 20 nodes | | Maintenance | 7 days’ notice; reschedule up to 14 days; deny periods up to 90 days | | Servers | Basic on one; Standard needs two | ## Pricing On your own servers, nodes use their capacity and are part of the server fee; backups count against the Frazer Storage allowance. | In-memory store | On your servers | On the Frazer fleet | | --- | --- | --- | | Price | **Included** | $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 | Every line, with the estimator: [pricing](https://frazer.ai/pricing#lines). ## Troubleshooting | Symptom | Cause | Fix | | --- | --- | --- | | Writes fail with OOM errors | Memory is full and the eviction policy is `noeviction` | Set an eviction policy such as `allkeys-lru`, add TTLs, or move to a bigger node type | | A client fails against a Cluster instance | The client is not cluster-aware | Use a cluster-aware client such as Valkey GLIDE | | `KEYS` or `CONFIG` is refused | Admin commands are blocked for your users | Use `SCAN`; change settings with `frazer keyvalue instances update` | | Writes went missing after a failover | Replication is asynchronous | Use `WAIT` for writes that must reach a replica | | The create page offers Basic only | The site has one server | Add a server; Standard needs two | | You need another mode | The mode is fixed at create | Create a new instance from a backup | | An RDB import is refused | The file uses a newer format than Valkey reads | Import a file from Valkey or from Redis® Open Source 7.2 or earlier, copy the keys from the running server, or start empty | | Data is gone after a Basic resize | Persistence was off | Turn on RDB or AOF before resizing | ## Reference ### CLI | Command | What it does | | --- | --- | | `frazer keyvalue instances create` | Create an instance from a plan (alias frazer kv). | | `frazer keyvalue instances list` | List instances across engines and sites. | | `frazer keyvalue instances describe` | Show an instance with its endpoints, nodes and backups. | | `frazer keyvalue instances update` | Change node type, replicas, shards or settings through a plan. | | `frazer keyvalue instances connect` | Open the engine's command-line client over Frazer Link with a short-lived IAM login. | | `frazer keyvalue instances proxy` | Serve an instance on a local port for apps on your laptop. | | `frazer keyvalue instances failover` | Fail over to a replica, as an audited live action. | | `frazer keyvalue instances restore` | Restore a backup into a new instance. | | `frazer keyvalue instances import` | Create an instance from an RDB file in a bucket. | | `frazer keyvalue users create` | Create an ACL user from a template. | | `frazer keyvalue backups list` | List an instance's backups, including final ones. | | `frazer keyvalue backups create` | Take an on-demand backup. | All of them: [CLI reference](https://frazer.ai/docs/cli). ### Terraform and OpenTofu | Resource | What it manages | | --- | --- | | `frazer_keyvalue_instance` | An In-memory store instance in a project. | All of them: [Terraform and OpenTofu reference](https://frazer.ai/docs/terraform). ### MCP tools | Tool | What it does | | --- | --- | | `keyvalue_instances_list` | List instances. | | `keyvalue_instances_get` | Describe an instance. | | `keyvalue_instances_get_metrics` | Read an instance's metrics. | | `keyvalue_insights_big_keys` | List the biggest keys. | | `keyvalue_insights_command_log` | Read the command log of slow and large commands. | | `keyvalue_instances_scan` | Scan keys read-only, with value previews capped at 1 KiB. | | `keyvalue_instances_create` | Plan a change, failover, flush or delete. Writes become a plan that waits for approval. | All of them: [MCP tools reference](https://frazer.ai/docs/mcp). ### Events | Event type | When it is sent | | --- | --- | | `frazer.keyvalue.failover.v1` | A replica took over from the primary. | All of them: [Events reference](https://frazer.ai/docs/webhooks). ## Related - [In-memory store product page](https://frazer.ai/memory) - [Databases](https://frazer.ai/docs/databases), which share the data cluster, endpoints and maintenance calendar - [Secrets](https://frazer.ai/docs/secrets) for ACL passwords and rotation - [Serverless](https://frazer.ai/docs/serverless) for `VALKEY_URL` bindings - [Frazer Storage](https://frazer.ai/docs/storage) for RDB import and export - [Frazer Monitoring](https://frazer.ai/docs/monitoring) for metrics and alerts 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. ## Pages in Data - [Databases](https://frazer.ai/docs/databases.md) - [In-memory store](https://frazer.ai/docs/memory.md) (this page) - [Frazer Storage](https://frazer.ai/docs/storage.md) - [Secrets](https://frazer.ai/docs/secrets.md) - [Volumes and snapshots](https://frazer.ai/docs/volumes.md)