Valkey

Valkey is a managed engine alongside PostgreSQL. Relay operates the cluster's nodes, failover, TLS, users, backups, and restore, the same way it does for PostgreSQL clusters. This page covers where Valkey differs.

Versions

Versions 9.1 (latest, default), 9.0, and 8.1 are selectable. Version upgrades are applied in place; downgrades are not supported.

Modes

The mode is chosen at creation and cannot be changed afterwards.

Replication

One primary and its replicas, with automatic failover through Sentinel. A single-node cluster has no failover.

Two endpoints are exposed:

• <name>.<segment>.<base> — read-write, always the current primary.
• <name>-ro.<segment>.<base> — read-only, routed to the replicas, or to the primary when the cluster has a single node.

Cluster

Data is sharded across 3 to 100 shards, each with 0 to 4 replicas. The total number of nodes is shards × (1 + replicas per shard): 3 shards with 1 replica each is 6 nodes.

Clients must be cluster-aware — redis-cli -c, or a cluster client in your library. Every node is announced by a public hostname, so MOVED and ASK redirects resolve from outside the platform. There is no read-only endpoint in cluster mode.

Provisioning

The dashboard offers the same two flows as for PostgreSQL:

• Quick — single node, high availability (replication with replicas), or cluster (3 shards × 1 replica).
• Advanced — mode; nodes, or shards and replicas per shard; node size; storage, IOPS, and storage autoscaling; and parameters.

Not available for Valkey: logical databases, the PostgreSQL parameter catalog (Valkey has its own), point-in-time recovery, maintenance window selection in the wizard, and multi-region distribution.

Connecting

Connections are TLS only, on port 6379. The server presents a publicly trusted certificate, so there is no CA to download.

redis-cli --tls --sni <host> -h <host> -p 6379 --user <user> --pass <password> ping
valkey-cli --tls --sni <host> -h <host> -p 6379 --user <user> --pass <password> ping

The URI form uses the rediss:// scheme:

rediss://<user>:<password>@<host>:6379

In cluster mode, add -c to redis-cli / valkey-cli so it follows redirects.

Network access

Public endpoints are gated by the workspace IP allowlist, managed on the workspace's Network page. With no entries, all public access is denied — add your IP or CIDR range before connecting.

Private endpoints (AWS PrivateLink) are supported in both modes. In cluster mode, private traffic goes through a proxy that rewrites the cluster topology, so redirects point at private hostnames.

Users & roles

The platform-managed default user is disabled. Create users from the cluster's Users tab. Authentication is by password only.

Every role can run the cluster-topology commands (CLUSTER SLOTS, CLUSTER SHARDS, CLUSTER NODES, READONLY), so cluster clients work with any role.

• Username — lowercase letters, digits, and hyphens, starting with a letter, up to 63 characters. default and names starting with relay- are reserved.
• Expiry — a user can be given an expiry date.
• Password rotation — set a new password on an existing user to rotate it.

Memory & persistence

Relay sets maxmemory to 50% of the node's memory. maxmemory-policy defaults to noeviction: once memory is full, writes that need more memory fail. Change the policy through parameters if you want eviction.

Persistence is RDB only: a snapshot is written when a node shuts down and before each backup, and never periodically unless you set save. A crash or out-of-memory kill of the primary can lose the writes since its last snapshot, in replicated clusters too. See persistence and durability.

Parameters

Set valkey.conf parameters from the cluster's Parameters tab, or at creation in the Advanced flow. See Valkey parameters for value formats, which changes trigger a rolling restart, and the parameters the platform manages.

Backups

Enable backups from the cluster's Backups tab. Backups are volume snapshots of a replica in each shard, and each snapshot is also exported to the platform object store.

Schedules use the same retention tiers as PostgreSQL:

On-demand backups, with a retention you choose, work as described in Backups & restore. There is no point-in-time recovery.

Restore

A restore creates a new cluster from the source cluster's latest completed backup; you cannot choose an earlier backup or a point in time. The new cluster has the same mode and shard count as the source. Users are recreated on the restored cluster.

Restoring from backups kept after deleting a cluster is supported for Valkey.

Lifecycle & metrics

Pause, resume and metrics work as for PostgreSQL clusters.