Vercel KV alternatives: own your Redis in 2026

Vercel KV was Vercel's first-party key/value store: Redis, with Upstash running underneath and a @vercel/kv client that worked nicely from the edge. It is not a product you can buy anymore. Vercel's Redis docs say "Vercel KV is no longer available" and that existing stores were automatically moved to Upstash Redis in December 2024, with new projects pointed at a Redis integration from the Marketplace. So if you still think of your store as Vercel KV, what you actually hold is a metered Upstash Redis database. That makes it a good moment to ask a different question: do you want to keep renting Redis through a per-request meter, or own an instance at a flat price?

If the answer is "own it," Valkey on Layerbase Cloud is a managed, Redis-compatible instance with flat per-instance pricing. Because the store was always Redis, your data is portable with a single rediss:// connection string, and the only code change is swapping the deprecated @vercel/kv client for a standard Redis driver.

Just want it done? Start at layerbase.com/migrate/vercel-kv. You sign in, the wizard opens with Vercel KV already selected, and it reads your store once with a non-blocking scan and copies every key, type, and TTL into managed Redis (or Valkey): read-once, nothing written back to your KV store. For the step-by-step version, see Migrating from Vercel KV to Layerbase.

Contents

• What Vercel KV Actually Was
• Set Up Valkey Locally with the Layerbase CLI
• Copy Your Data
• Swap the Client
• What to Test
• The Managed Path: Layerbase Cloud

What Vercel KV Actually Was

KV was Redis. Vercel exposed it two ways: a KV_URL (a standard rediss:// connection string) and a REST API (KV_REST_API_URL + KV_REST_API_TOKEN) that the @vercel/kv package used for edge runtimes. That was the same shape as Upstash, because it was Upstash, and after the December 2024 move it is Upstash without the Vercel wrapper.

Which of those variables your project still carries depends on when it was provisioned: older ones often keep the KV_* set, newer ones get the Upstash pair instead. Neither vendor publishes a definitive list of what the integration injects today, so read your project's actual environment list and take whichever variable holds a rediss:// string.

So moving off it is the same as moving any Redis:

• Your keys, types, and TTLs copy over with the rediss:// URL.
• The @vercel/kv client (REST) becomes a standard Redis client (ioredis) on a Node runtime, or stays HTTP-shaped if you genuinely need edge access.
• Flat per-instance pricing replaces the per-request meter.

Set Up Valkey Locally with the Layerbase CLI

Stand up Valkey locally so you can copy into it and verify first. The Layerbase CLI (formerly SpinDB) runs it with one CLI, no Docker. (What is the Layerbase CLI?)

npm i -g layerbase    # npm
pnpm add -g layerbase # pnpm

lbase create vercel-kv-migration -e valkey --start
lbase url vercel-kv-migration

redis://127.0.0.1:6380

The redis:// scheme is correct; Valkey speaks the same protocol as Redis.

Copy Your Data

The managed wizard (paste your connection string)

On Layerbase Cloud, choose Migrating from another platform, pick the connection-string option, and paste the rediss:// value. As of August 2026 you find it by opening your Vercel project's Storage tab, selecting the Redis resource, and following the link into the Upstash console, where the database page lists the TLS endpoint; a legacy KV_URL still sitting in your environment works just as well. It reads the keyspace once with a non-blocking SCAN and copies every key, type, and TTL into a fresh managed Valkey. No REST tokens, no manual export.

By hand with a scan + dump

That connection string is a normal rediss:// endpoint, so redis-cli works directly. Use --scan (never KEYS *) and DUMP/RESTORE to preserve types and TTLs:

SRC='rediss://default:<token>@<name>.upstash.io:6379'
DST='redis://127.0.0.1:6380'        # or your Layerbase Valkey rediss:// URL

redis-cli -u "$SRC" --scan | while read -r key; do
  ttl=$(redis-cli -u "$SRC" --no-raw PTTL "$key")
  dump=$(redis-cli -u "$SRC" --no-raw DUMP "$key")
  redis-cli -u "$DST" RESTORE "$key" "${ttl/-1/0}" "$dump"
done

For large keyspaces, the managed wizard batches and resumes; the loop is fine for typical cache/session data.

Swap the Client

The one code change is the client. @vercel/kv is the Upstash REST client with a Vercel wrapper, and npm now marks it deprecated.

Before (@vercel/kv):

import { kv } from '@vercel/kv'

await kv.set('session:42', value, { ex: 3600 })
const v = await kv.get('session:42')

After (standard Redis client over TCP):

import Redis from 'ioredis'

const redis = new Redis(process.env.REDIS_URL!) // your Valkey rediss:// URL
await redis.set('session:42', JSON.stringify(value), 'EX', 3600)
const v = JSON.parse((await redis.get('session:42')) ?? 'null')

Two small differences: ioredis stores strings, so serialize objects yourself (@vercel/kv auto-JSON-encoded), and the expiry option is 'EX', seconds rather than { ex: seconds }. If you deploy to a Node runtime, this is the simpler path. If you need HTTP from an edge function, keep that path behind a small Node API route that talks to Valkey over TCP.

What to Test

• Run your suite against the local Valkey before cutting over.
• Check JSON handling. Since @vercel/kv auto-encoded values, audit every get/set to add explicit JSON.stringify/JSON.parse (or use a small wrapper) so you don't store [object Object].
• Confirm TTLs carried across on sessions and rate-limit keys (PTTL a few).
• Use one client per instance, not one per request, especially in serverless.

The Managed Path: Layerbase Cloud

Worth doing the copy once by hand to see the shape. When you want managed Valkey you own, Layerbase Cloud provisions it with TLS, backups, and flat per-instance pricing, and the Migrating from another platform flow copies your data from the rediss:// string you already have. Off the per-request meter, onto an instance that's yours.

Wrapping Up

Vercel KV was Redis, so leaving it is a data copy plus a one-client swap: paste the rediss:// string into the wizard (or run a --scan + DUMP/RESTORE loop), then replace @vercel/kv with ioredis and handle JSON encoding yourself. The payoff is a flat-priced Redis you control.

Manage your local Valkey instance with the Layerbase CLI:

lbase stop vercel-kv-migration    # Stop the server
lbase start vercel-kv-migration   # Start it again
lbase url vercel-kv-migration     # Print the connection URL
lbase list                        # See all your instances

The Layerbase CLI handles 20+ database engines, so Valkey can sit next to your Postgres or Meilisearch while you verify the move. Layerbase Desktop wraps it in a GUI on macOS. Coming from Upstash directly? See Migrating from Upstash to Layerbase.