CapyDB Knight/Valkyrie

K/V

Un magasin clé-valeur et limiteur de débit qui tourne dans sa propre cellule, à côté de vos données — et qui fonctionne très bien sans aucune base de données.

01où il vit

À côté de vos données

Le stockage est une cellule, comme votre base est une cellule, sur le même nœud. Votre application l'atteint par le même saut que votre base, et le stockage répond en une fraction de milliseconde dès que la requête arrive.

01où il vit
awaiting signal

02ce qu'il fait

Trois passent, le reste attend

Un limiteur de débit est ce pour quoi la plupart des gens veulent un stockage clé-valeur, et ce qu'un extrait de code montre le plus mal. Trois requêtes passent dans la fenêtre ; la quatrième non, sans qu'aucune ne touche une base de données.

02ce qu'il fait
awaiting signal

03ce qu'il vous coûte

Deux variables

Le stockage parle le protocole que votre client parle déjà : le limiteur ci-dessus ne change jamais. Seule l'origine des identifiants diffère, et cela tient en deux lignes d'environnement.

03ce qu'il vous coûte
awaiting signal

01

Ce que c'est

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 en TLS — de sorte que les clients dont vous disposez déjà fonctionnent avec lui : les clients REST avec leurs réglages par défaut, les clients RESP dès qu'ils envoient le nom d'hôte comme nom de serveur TLS.

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.

02

Limitation de débit

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.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

Seul

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 — marquez le projet hors production et une cellule inutilisée se met en pause d'elle-même et ne consomme rien.

04

Isolation

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.

05

Compatibilité

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 en TLS, pour les clients Redis® OSS ordinaires : ioredis, node-redis, redis-py, go-redis, redis-cli. Commandes bloquantes et pub/sub compris. Le point de terminaison route selon le nom de serveur TLS (SNI) : redis-py et go-redis l'envoient d'eux-mêmes, ioredis a besoin de tls.servername et redis-cli de --sni.
  • -Propulsé par Valkey. Redis est une marque déposée de Redis Ltd. ; CapyDB n'est ni affilié à Redis Ltd. ni approuvé par elle.

06

Capacité

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

07

La durabilité, honnêtement

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é.

08

Pour commencer

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à.