DataProduct page Pricing

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, 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.

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)

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.

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
Console

Plan the instance. The plan changes nothing.

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

Apply it: run the same command without --dry-run.
Check the instance and its endpoints.
Terminal window
```
frazer keyvalue instances describe cart-cache
```

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.

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.

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:

frazer keyvalue instances connect cart-cache --readonly
frazer keyvalue instances proxy cart-cache --port 6379

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.

frazer keyvalue backups list cart-cache
frazer keyvalue backups create cart-cache

# Restore always creates a new instance
frazer keyvalue instances restore <backup> --to cart-cache-r

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. 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.

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

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

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:

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 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.

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.

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.

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.

Events

Event type	When it is sent
`frazer.keyvalue.failover.v1`	A replica took over from the primary.

All of them: Events reference.

In-memory store product page
Databases, which share the data cluster, endpoints and maintenance calendar
Secrets for ACL passwords and rotation
Serverless for VALKEY_URL bindings
Frazer Storage for RDB import and export
Frazer 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.