Valkey 9 on Layerbase Cloud: what you get, and what 9.1 will add

Short version: a new Valkey database on Layerbase Cloud runs 9.0, and has since spring. The build we ship today is 9.0.5, the July security release that closed CVE-2026-56684 (a TLS use-after-free reachable by an authenticated client through CLIENT KILL) and CVE-2026-63639 (a corrupt stream RDB leading to remote code execution), which reached our fleet in the August engine wave. The headline features in Valkey 9 are hash field expiration, atomic slot migration, numbered databases in cluster mode, and a stack of throughput work. Only some of that applies to a single managed instance, and I will say which. Nothing changes about how you connect: RESP over TLS on port 6379, the same rediss:// string, every Redis client unchanged. Databases already on 8.0 stay on 8.0. Valkey is on the Free tier, so you can try 9.0 without a card.

Valkey 9.0 went GA on October 21, 2025, the biggest release since the project forked from Redis 7.2.4 under the Linux Foundation. We did not adopt it that week. The version you create a database on is the version you keep, so the default has to be a version we would be comfortable being stuck on, and that means waiting for the point releases to shake out. 9.0 became the default here once they had, and the patch moves with upstream's security releases: 9.0.4 to 9.0.5 in August, for the two CVEs above.

What is actually in Valkey 9

The Valkey 9 announcement and the Linux Foundation release cover it at length. The items that matter:

Hash field expiration. Until 9.0, expiry was all-or-nothing per key: a hash lived or died as a unit. 9.0 adds HEXPIRE, HEXPIREAT, HTTL, HPERSIST, HGETEX, and their relatives, so an individual field inside a hash can carry its own TTL. If you have ever kept a per-user hash and wanted one field in it to lapse, you have been emulating this with a second key and a cleanup job.

Atomic slot migration. Cluster resharding used to move keys one at a time, with a move-then-delete sequence per key. Mid-migration, a client could not know whether a key lived on the old node or the new one, which meant MOVED and ASK redirects, extra hops, and latency spikes whenever a large collection was in flight. 9.0 migrates a whole slot atomically, in AOF format, from one node to another.

Numbered databases in cluster mode. Cluster mode was restricted to db 0. 9.0 gives it full support for numbered databases, so SELECT works in a cluster.

Scale. Their testing has 2,000-node clusters serving over one billion requests per second.

The throughput work. Pipeline memory prefetching for up to 40% higher throughput on pipelined workloads, zero-copy responses for up to 20%, multipath TCP cutting latency around 25% where the network supports it, and SIMD optimizations in hot paths. Plus new cluster failover configuration options and Lua script safety improvements.

What a single Layerbase Valkey gets from that

Honesty section. A managed Valkey on Layerbase is one instance, not a cluster. So atomic slot migration, multi-database cluster mode, and the 2,000-node number do not apply to your database here. They are real and they are why hyperscalers backed the project, but I am not going to list them as things you get.

What you do get:

Hash field expiration, which is the feature most apps will actually use. Sessions are the obvious case. One hash per session, and a short-lived field inside it, like a verification token, expires on its own:

redis-cli -u "$VALKEY_URL" HSET session:42 user_id 1001 token abc123
redis-cli -u "$VALKEY_URL" HEXPIRE session:42 3600 FIELDS 1 token
redis-cli -u "$VALKEY_URL" HTTL session:42 FIELDS 1 token

(integer) 2
1) (integer) 1
1) (integer) 3598

An hour later token is gone and user_id is still there. No second key, no sweeper.

The throughput and memory improvements. Pipelining, zero-copy responses, and the SIMD paths all apply to a single process. If your client pipelines, and most cache clients do, you get the prefetching gain for free.

The Lua safety and pipelining changes. Same story: single-node improvements, no configuration required.

Nothing changes when you connect

The wire protocol did not change. Your database still speaks RESP over TLS on port 6379, the connection string is still the rediss:// one from Quick Connect, and ioredis, node-redis, redis-py, redis-cli, and BullMQ all connect exactly as before. Valkey has been a drop-in for Redis clients since the fork and 9.0 does not alter that.

Two Layerbase-specific surfaces come along unchanged too. Every Valkey database exposes an Upstash-compatible REST endpoint alongside the TLS port, so @upstash/redis and Cloudflare Workers and anything else that cannot hold a TCP socket read and write the same keys. And every Valkey database carries vqueue, the HTTP webhook queue that speaks the @upstash/qstash client's API, so scheduled deliveries and retries ride on the database you already have. Both work on 8.0 and 9.0 identically.

Already on 8.0? Nothing moves underneath you

Databases created on Valkey 8.0 stay on 8.0. Start, stop, backup, restore, branching, and creating a new database on 8.0 all still work if your tooling is validated against that line. Nothing about 8.0 changes when the default patch moves, and 8.0 got its own fix for the same two CVEs in 8.0.10.

That is policy, not accident. A major version bump you did not schedule is an incident, not an upgrade. When you want 9.0 for an existing database, the path is a new database on 9.0 and a copy, which the Migrate tab does from your existing connection string with every key, type, and TTL preserved.

What about 9.1?

Valkey 9.1 shipped on May 19, 2026. It is the efficiency release: a redesigned I/O threading model for up to 17% more throughput, up to 20% less memory for strings under 128 bytes, database-level ACLs so a user can be scoped to specific numbered databases, automatic TLS certificate reloading, and new commands including HGETDEL, MSETEX, and CLUSTERSCAN.

We do not offer 9.1 yet. It goes through the same gate every engine version gets here, and I would rather say "not yet" than put a date on it and miss. When it lands it will show up in the version picker, and 9.0 databases will stay on 9.0 for the reason above.

Redis 7.2 is still here

If you specifically need upstream Redis, Layerbase still runs Redis 7.2, the last release before the license change. It is a fine choice if you have a compliance reason to want the Redis name on the tin. For new projects we recommend Valkey: same protocol, same clients, BSD license, and the version that is actually getting the performance work. Redis vs Valkey has the longer comparison and the licensing timeline.

On the free tier

Valkey is one of the 8 engines on the Free tier: 2 databases, 5 GB, no card, and no command meter. Idle databases sleep after 15 minutes and wake on the next connect. There is no counter running against your GETs, which is the part that distinguishes it from the per-command Redis hosts.

If you want to kick the tires locally first, the Layerbase CLI runs the same Valkey binary on your machine with lbase create cache -e valkey --start, no Docker.

Verified, not assumed

Every version we offer, a new major or a security patch like 9.0.5, clears the same gate before it reaches the version picker: the binary boots and serves on every platform we build for, backup and restore round-trip, the REST endpoint and vqueue answer, and a live database on the staging fleet reports what it should. For the curious, against a freshly created database:

redis-cli -u "rediss://default:<password>@<host>.cloud.layerbase.dev:6379" INFO server | grep valkey_version

valkey_version:9.0.5

FAQ

Will my existing Valkey database be upgraded to 9.0?

No. The version you created on is the version you keep. 8.0 stays fully supported for start, stop, backup, restore, branching, and new databases. To move an existing workload to 9.0, create a 9.0 database and copy into it from the Migrate tab.

Do I need to change my client or connection string?

No. RESP over TLS on 6379, the same rediss:// string, and every Redis client works unchanged. The REST endpoint and vqueue are identical on both versions.

Which Valkey 9 features apply to a single managed instance?

Hash field expiration, the pipelining and zero-copy throughput work, the SIMD paths, and the Lua improvements. Atomic slot migration, numbered databases in cluster mode, and the 2,000-node scale numbers are cluster features and do not apply to one instance.

How does hash field expiration work?

HEXPIRE key seconds FIELDS n field... sets a TTL on individual fields of a hash. HTTL reads it, HPERSIST removes it, HGETEX reads and sets in one call. The rest of the hash is untouched when a field lapses.

Is Valkey 9.1 available on Layerbase?

Not yet. 9.1 shipped May 19, 2026 with a new I/O threading model, database-level ACLs, and commands like HGETDEL and MSETEX. It will be offered once it clears our version gate, and 9.0 databases will stay on 9.0 when it does.

Is Valkey on the free tier?

Yes. 2 databases, 5 GB, no card, and no per-command meter. Free databases sleep after 15 idle minutes and wake on connect.

Create a Valkey database and you are on 9.0 in under a minute. The first HEXPIRE is on the house.