K/V

A managed key-value store, one per project, running in its own cell: its own process, its own memory ceiling, its own storage. It is powered by Valkey and speaks two protocols - the Upstash REST protocol over HTTPS, and RESP over TLS - so the clients you already have work against it: REST clients at their defaults, RESP clients once they send the hostname as the TLS server name.

It is meant for the work that wants a counter rather than a table: rate limits, sessions, queues, feature flags, short-lived caches. Postgres can do all of it and does none of it as cheaply.

This is the whole integration. Two environment variables and the limiter your framework already expects; nothing here is CapyDB-specific except where the credentials come from.

import { Ratelimit } from '@upstash/ratelimit'
import { Redis } from '@upstash/redis'

const ratelimit = new Ratelimit({
  redis: new Redis({
    url: process.env.CAPYKV_REST_URL!,
    token: process.env.CAPYKV_REST_TOKEN!,
  }),
  limiter: Ratelimit.slidingWindow(10, '10 s'),
})

export async function POST(request: Request) {
  const { success } = await ratelimit.limit(userIdFrom(request))
  if (!success) return new Response('Too many requests', { status: 429 })
  // ...
}

K/V is a feature in its own right, not something bolted to a database. You can add a store and never open the database beside it: no schema to design, no connection string to wire up, no migration to run. Plenty of applications want a rate limiter and nothing else, and that is a complete way to use CapyDB.

A store still belongs to a project, because a project is how CapyDB scopes billing, access and region. The project keeps a database cell you are free to ignore - mark the project non-production and an untouched cell pauses itself and consumes nothing.

A K/V store is a cell, the same runtime primitive a database gets. That is not a metaphor for a namespace in a shared server:

• -Its own process, with its own memory ceiling and CPU share enforced by the kernel - a neighbour cannot spend your memory.
• -Its own storage, its own credential, its own socket. There is no shared instance and no shared keyspace to collide in.
• -Reachable only through the authenticated endpoint. The store itself has no route to the public internet and none to your database.

Two protocols, both standard, so migrating in means changing a URL and a token:

• -The Upstash REST protocol, including pipelining, transactions and base64 encoding - @upstash/redis and @upstash/ratelimit work at their default settings.
• -RESP over TLS, for ordinary Redis® OSS clients: ioredis, node-redis, redis-py, go-redis, redis-cli. Blocking commands and pub/sub included. The endpoint routes by TLS server name (SNI): redis-py and go-redis send it on their own, ioredis needs tls.servername and redis-cli needs --sni.
• -Powered by Valkey. Redis is a registered trademark of Redis Ltd.; CapyDB is not affiliated with or endorsed by Redis Ltd.

K/V is included in every plan at that plan’s size - there is no separate K/V subscription and no per-command charge. The figures below are what the store will hold:

• -CapyDB Vibe: 32 MB
• -CapyDB Ship: 128 MB
• -CapyDB Business: 512 MB

A K/V store keeps a periodic snapshot, which means it survives a restart but is not a database. There are no backups, no point-in-time recovery and no replica, and the eviction policy will discard keys once the store is full.

Treat it as fast, expendable state: counters, sessions, caches, locks. Anything you would be unhappy to lose belongs in the database cell next door, which does have backups and point-in-time recovery.

Add a store from a project’s K/V tab in the dashboard. It provisions in seconds and hands you the endpoint and token once - the token is stored only as a hash, so copy it then.