> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stackshift.cloud/llms.txt
> Use this file to discover all available pages before exploring further.

# Valkey

> Valkey 9.0, a Redis-compatible key-value engine for caches, queues and sessions.

> [!TIP]
>
> **Live.** This area is documented as current, user-reliable behavior.

## Goal

Use Valkey for caches, queues, sessions and rate limits with your usual Redis client.

## Prerequisites

* A StackShift account
* Any Redis client library

## Workflow

**Step 1**

Create a database and choose Valkey. Version 9.0 is the only version offered.

**Step 2**

Connect with the `rediss://` connection string from the database page. Redis client libraries work unchanged.

**Step 3**

Bind it to your app so `REDIS_URL` is set for you, then test a real job, cache write or session, not only `PING`.

## What Valkey is

Valkey is a Redis-compatible key-value engine. It speaks the Redis protocol and supports the core Redis commands, so you use `rediss://` URLs, `REDIS_URL` and your current client libraries. Both `valkey-cli` and `redis-cli` connect.

## Redis or Valkey

* Choose Valkey for caching, queues (BullMQ, Sidekiq, Celery, Laravel queues), sessions and rate limits.
* Choose Redis when you need JSON documents, search, vector search, time series or Bloom filters. Those commands (`JSON.*`, `FT.*`, `TS.*`, `BF.*`) are not available on Valkey.
* In the API, CLI and Terraform the engine is `valkey`. `redis` means Redis 8.
* Valkey is BSD-licensed; Redis 8 runs under the AGPLv3 licence.

## Standby

An optional standby with automatic failover is rolling out for Redis and Valkey databases on StackShift servers. If your database page doesn't offer a standby, it isn't switched on for your account yet. Standbys are not available for databases on your own servers.

Turn it on from the database page or with `PUT /api/v1/databases/{id}/standby` and `{"mode": "async"}`; send `{"mode": "off"}` to turn it off. `sync` is not offered for Redis or Valkey. `GET /api/v1/databases/{id}/standby` shows its `state` (`enabling`, `active`, `degraded`, `failing_over`, `disabling`, `disabled` or `failed`), which server is serving (`master`: `home` or `standby`), how many failovers happened and when the last one was. The database needs a recent backup that passed its restore check first.

* The standby runs on another server. If the main server fails, the standby takes over in about 20 to 35 seconds.
* Your connection string and `REDIS_URL` never change; clients reconnect on their own.
* When the failed server comes back, it rejoins as the standby. Switching back to the main server pauses writes for 1 to 3 seconds.
* If only the standby is lost, your database keeps accepting writes.
* Copying to the standby is asynchronous, so a failover can lose about the last second of writes after a crash, or up to about 5 seconds if the main server is cut off from the network.
* Each failover shows up in your operations events.
* The standby is billed hourly as a second database of the same size.
* While a standby is on, stopping the database is refused. Deleting the database turns the standby off first.

## Limits

* Valkey has no connection pooler; clients keep their own connections.
* Valkey is not eligible for SQL Import / Export.

## Expected result

> [!TIP]
>
> Your app reads and writes keys through its usual Redis client.

## Common failures

> [!WARNING]
>
> * TLS handshake errors: connect with `rediss://` and the CA certificate from the database page.
> * `unknown command 'JSON.SET'` or `'FT.SEARCH'`: those commands need Redis. Create a Redis database instead.

## Related guides

> **[Redis](https://docs.stackshift.cloud/databases/redis.md)**
>
> Redis 8.10 with JSON, search, vector search, time series and Bloom filters built in.

> **[Create a database](https://docs.stackshift.cloud/databases/create-a-database.md)**
>
> Create a hosted or connected-node database with private, direct public, or StackShift tunnel access.

> **[Database connections and tunneling](https://docs.stackshift.cloud/databases/credentials-pooling-and-usage.md)**
>
> Use private, direct public, or StackShift tunnel endpoints with TLS and explicit client IP policy.

> **[Back up and restore a database](https://docs.stackshift.cloud/databases/back-up-and-restore-a-database.md)**
>
> Use durable recovery storage correctly and understand why backups are independent from portable SQL transfers.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.