CapyDB Knight/Valkyrie

K/V

Ein Key-Value-Speicher und Rate Limiter, der in einer eigenen Zelle neben deinen Daten läuft – und ganz ohne Datenbank genauso gut funktioniert.

01wo er läuft

Neben deinen Daten

Der Speicher ist eine Zelle, so wie deine Datenbank eine Zelle ist - auf demselben Node. Deine App erreicht ihn über denselben einen Hop wie deine Datenbank, und der Speicher antwortet in Bruchteilen einer Millisekunde, sobald die Anfrage ankommt.

01wo er läuft
awaiting signal

02was er tut

Drei durch, der Rest wartet

Ein Rate Limiter ist das, wofür die meisten einen Key-Value-Speicher wollen - und das, was sich aus einem Snippet am schlechtesten vorstellen lässt. Drei Anfragen kommen im Fenster durch, die vierte nicht, ohne dass eine davon eine Datenbank berührt.

02was er tut
awaiting signal

03was es dich kostet

Zwei Variablen

Der Speicher spricht das Protokoll, das dein Client ohnehin spricht - der Limiter oben ändert sich nie. Anders ist nur, woher die Zugangsdaten kommen, und das sind zwei Zeilen Umgebung.

03was es dich kostet
awaiting signal

01

Was es ist

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 über TLS –, sodass die Clients, die du bereits hast, damit arbeiten: REST-Clients mit ihren Standardeinstellungen, RESP-Clients, sobald sie den Hostnamen als TLS-Servernamen senden.

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.

02

Rate Limiting

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.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 })
  // ...
}

03

Für sich allein

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 – markierst du das Projekt als Nicht-Produktion, pausiert sich eine unberührte Zelle selbst und verbraucht nichts.

04

Isolation

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.

05

Kompatibilität

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 über TLS, für gewöhnliche Redis®-OSS-Clients: ioredis, node-redis, redis-py, go-redis, redis-cli. Blockierende Befehle und Pub/Sub inbegriffen. Der Endpunkt routet nach TLS-Servernamen (SNI): redis-py und go-redis senden ihn von selbst, ioredis braucht tls.servername und redis-cli --sni.
  • -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.

06

Kapazität

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

07

Beständigkeit, ehrlich gesagt

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.

08

Loslegen

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.