Vercel KV: Redis-Compatible Key-Value Storage (2026)

Vercel KV is a fully managed, Redis-compatible key-value store that feels like magic until you realize it’s just really well-engineered Redis.

Let’s peek under the hood. Imagine you have a Next.js app deployed on Vercel, and you want to store some session data, user preferences, or cache API responses. Instead of spinning up your own Redis instance, managing its security, scaling it, and worrying about network latency from your Vercel deployment, you can just use Vercel KV. It’s a global, distributed Redis database that Vercel provisions and manages for you, accessible directly from your serverless functions.

Here’s a taste of it in action.

// pages/api/set-data.js
import { createClient } from '@vercel/kv';

export default async function handler(req, res) {
  const client = createClient({
    url: process.env.KV_REST_API_URL,
    token: process.env.KV_REST_API_TOKEN,
  });

  const { key, value } = req.body;

  await client.set(key, value);

  res.status(200).json({ message: 'Data set successfully' });
}

// pages/api/get-data.js
import { createClient } from '@vercel/kv';

export default async function handler(req, res) {
  const client = createClient({
    url: process.env.KV_REST_API_URL,
    token: process.env.KV_REST_API_TOKEN,
  });

  const { key } = req.query;

  const value = await client.get(key);

  res.status(200).json({ value });
}

When you deploy this to Vercel, the process.env.KV_REST_API_URL and process.env.KV_REST_API_TOKEN are automatically injected into your serverless functions. Vercel KV uses a RESTful API on top of Redis, which is what the @vercel/kv SDK abstracts away. This means you’re not directly connecting to a traditional Redis TCP socket; instead, you’re making HTTP requests to Vercel’s global edge network.

The core problem Vercel KV solves is the operational overhead of managing a distributed database. For applications deployed on serverless platforms like Vercel, traditional database deployments often introduce significant latency due to network hops or require complex setup for high availability and scaling. Vercel KV aims to provide Redis-like performance and features without the infrastructure burden. It’s designed to be co-located with your compute, meaning your serverless functions can access the data with minimal latency, as Vercel KV endpoints are globally distributed.

Internally, Vercel KV is built on top of a managed Redis cluster. However, the key difference is the access pattern. Instead of a direct TCP connection, it exposes a REST API. This REST API is then routed to the nearest Vercel KV instance. This architecture allows Vercel to provide a global network of Redis instances that your application can connect to, effectively acting as a single, unified Redis database. The createClient function from @vercel/kv handles the authentication and constructs the correct HTTP requests to this API. You can use standard Redis commands like SET, GET, DEL, HSET, LPUSH, RPUSH, and many more, all translated into their RESTful API equivalents.

You control Vercel KV through environment variables provided by Vercel upon creating a KV store in your project settings. These are KV_REST_API_URL and KV_REST_API_TOKEN. Beyond that, your control is entirely through the Redis commands you issue. You can set expiration times on keys using EX (seconds) or PX (milliseconds) with your SET commands, for example: await client.set('mykey', 'myvalue', { ex: 3600 }); This sets 'myvalue' for 'mykey' to expire in one hour. You can also manage data structures like lists, sets, and hashes using commands like LPUSH, SADD, and HSET.

The ability to use Redis commands like SCAN or KEYS is intentionally limited in Vercel KV’s public API. While the underlying Redis instance supports these, the REST API abstracts them to prevent potentially long-running operations that could impact the performance and stability of the shared infrastructure. Instead, Vercel KV encourages patterns that involve fetching specific keys or iterating using cursor-based methods if absolutely necessary and supported through specific SDK methods, pushing developers towards more efficient data access patterns.

The next concept you’ll likely encounter is managing data consistency and potential race conditions in a distributed, eventually consistent environment, especially when dealing with complex transactions.