K/V

Un magasin clé-valeur géré, un par projet, tournant dans sa propre cellule : son processus, sa limite de mémoire, son stockage. Il est propulsé par Valkey et parle deux protocoles — le protocole REST d'Upstash en HTTPS, et RESP sur le fil — de sorte que les clients dont vous disposez déjà fonctionnent sans modification.

Il est fait pour le travail qui appelle un compteur plutôt qu'une table : limites de débit, sessions, files d'attente, drapeaux de fonctionnalité, caches éphémères. Postgres sait tout faire, et rien de tout cela à ce prix.

Voici l'intégration entière. Deux variables d'environnement et le limiteur que votre framework attend déjà ; rien ici n'est spécifique à CapyDB, sinon l'origine des identifiants.

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 est une fonctionnalité à part entière, pas un accessoire greffé sur une base de données. Vous pouvez ajouter un magasin et n'ouvrir jamais la base à côté : aucun schéma à concevoir, aucune chaîne de connexion à câbler, aucune migration à exécuter. Beaucoup d'applications veulent un limiteur de débit et rien d'autre, et c'est une manière complète d'utiliser CapyDB.

Un magasin appartient tout de même à un projet, car c'est par le projet que CapyDB cadre la facturation, les accès et la région. Le projet conserve une cellule de base de données que vous êtes libre d'ignorer — une cellule inutilisée se met en pause d'elle-même et ne consomme rien.

Un magasin K/V est une cellule, la même primitive d'exécution qu'obtient une base de données. Ce n'est pas une métaphore pour un espace de noms dans un serveur partagé :

• -Son propre processus, avec sa limite de mémoire et sa part de CPU imposées par le noyau — un voisin ne peut pas dépenser votre mémoire.
• -Son propre stockage, ses propres identifiants, sa propre socket. Il n'y a ni instance partagée ni espace de clés commun où entrer en collision.
• -Joignable uniquement par le point de terminaison authentifié. Le magasin lui-même n'a aucune route vers l'internet public ni vers votre base de données.

Deux protocoles, tous deux standards, si bien que migrer revient à changer une URL et un jeton :

• -Le protocole REST d'Upstash, y compris le pipelining, les transactions et l'encodage base64 — @upstash/redis et @upstash/ratelimit fonctionnent avec leurs réglages par défaut.
• -RESP, pour les clients Redis® OSS ordinaires : ioredis, node-redis, redis-py, go-redis, redis-cli. Commandes bloquantes et pub/sub compris.
• -Propulsé par Valkey. Redis est une marque déposée de Redis Ltd. ; CapyDB n'est ni affilié à Redis Ltd. ni approuvé par elle.

K/V est compris dans chaque formule, à la taille de cette formule — il n'y a ni abonnement K/V distinct ni facturation à la commande. Les chiffres ci-dessous correspondent à ce que le magasin contiendra :

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

Un magasin K/V conserve un instantané périodique : il survit donc à un redémarrage, mais ce n'est pas une base de données. Il n'y a ni sauvegardes, ni restauration à un instant donné, ni réplique, et la politique d'éviction écartera des clés une fois le magasin plein.

Considérez-le comme un état rapide et jetable : compteurs, sessions, caches, verrous. Tout ce dont la perte vous ennuierait appartient à la cellule de base de données voisine, qui dispose bien de sauvegardes et de restauration à un instant donné.

Ajoutez un magasin depuis l'onglet K/V d'un projet dans le tableau de bord. Il est provisionné en quelques secondes et vous remet le point de terminaison et le jeton une seule fois — le jeton n'est conservé que sous forme d'empreinte, copiez-le à ce moment-là.