K/V

Ein verwalteter Key-Value-Speicher, einer pro Projekt, in einer eigenen Zelle: eigener Prozess, eigene Speicherobergrenze, eigener Speicherplatz. Er wird von Valkey betrieben und spricht zwei Protokolle – das Upstash-REST-Protokoll über HTTPS und RESP auf der Leitung – sodass die Clients, die du bereits hast, unverändert damit arbeiten.

Gedacht ist er für die Arbeit, die einen Zähler will statt einer Tabelle: Rate Limits, Sessions, Queues, Feature Flags, kurzlebige Caches. Postgres kann das alles und nichts davon so günstig.

Das ist die gesamte Integration. Zwei Umgebungsvariablen und der Limiter, den dein Framework ohnehin erwartet; nichts daran ist CapyDB-spezifisch außer der Herkunft der Zugangsdaten.

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

const ratelimit = new Ratelimit({
  redis: new Redis({
    url: process.env.CAPYDB_KV_REST_URL!,
    token: process.env.CAPYDB_KV_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 ist ein eigenständiges Feature, nichts, was an eine Datenbank geschraubt wurde. Du kannst einen Speicher anlegen und die Datenbank daneben nie öffnen: kein Schema zu entwerfen, kein Connection String zu verdrahten, keine Migration auszuführen. Viele Anwendungen wollen einen Rate Limiter und sonst nichts, und das ist eine vollwertige Art, CapyDB zu nutzen.

Ein Speicher gehört trotzdem zu einem Projekt, denn über das Projekt regelt CapyDB Abrechnung, Zugriff und Region. Das Projekt behält eine Datenbankzelle, die du ignorieren darfst – eine unberührte Zelle pausiert sich selbst und verbraucht nichts.

Ein K/V-Speicher ist eine Zelle, dasselbe Laufzeit-Primitiv, das eine Datenbank bekommt. Das ist keine Metapher für einen Namensraum in einem gemeinsamen Server:

• -Eigener Prozess, mit eigener Speicherobergrenze und eigenem CPU-Anteil, durchgesetzt vom Kernel – ein Nachbar kann deinen Speicher nicht verbrauchen.
• -Eigener Speicherplatz, eigene Zugangsdaten, eigener Socket. Es gibt keine gemeinsame Instanz und keinen gemeinsamen Schlüsselraum, in dem etwas kollidieren könnte.
• -Erreichbar nur über den authentifizierten Endpunkt. Der Speicher selbst hat keine Route ins öffentliche Internet und keine zu deiner Datenbank.

Zwei Protokolle, beide Standard, sodass ein Umzug hierher nur eine URL und ein Token ändert:

• -Das Upstash-REST-Protokoll, inklusive Pipelining, Transaktionen und Base64-Kodierung – @upstash/redis und @upstash/ratelimit funktionieren in ihren Standardeinstellungen.
• -RESP, für gewöhnliche Redis®-OSS-Clients: ioredis, node-redis, redis-py, go-redis, redis-cli. Blockierende Befehle und Pub/Sub inbegriffen.
• -Powered by Valkey. Redis ist eine eingetragene Marke von Redis Ltd.; CapyDB steht in keiner Verbindung zu Redis Ltd. und wird von dort nicht unterstützt.

K/V ist in jedem Tarif in der Größe dieses Tarifs enthalten – es gibt kein eigenes K/V-Abonnement und keine Abrechnung pro Befehl. Die folgenden Werte sind das, was der Speicher fasst:

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

Ein K/V-Speicher hält einen regelmäßigen Snapshot vor, übersteht also einen Neustart, ist aber keine Datenbank. Es gibt keine Backups, keine Point-in-Time-Wiederherstellung und kein Replikat, und die Verdrängungsstrategie verwirft Schlüssel, sobald der Speicher voll ist.

Betrachte ihn als schnellen, entbehrlichen Zustand: Zähler, Sessions, Caches, Locks. Alles, dessen Verlust dich stören würde, gehört in die Datenbankzelle nebenan, die Backups und Point-in-Time-Wiederherstellung hat.

Lege im Dashboard über den Tab K/V eines Projekts einen Speicher an. Er ist in Sekunden bereit und gibt dir Endpunkt und Token einmalig – das Token wird nur als Hash gespeichert, kopiere es also gleich.