CapyDB
Commencer gratuitement

Journal des modifications

Changements récents.

Les changements réellement présents dans le produit et sur le site. Pas de vaporware, pas de feuille de route à interpréter.

Cloudflare Workers, Netlify et huit langues

  • -Connectez un compte Cloudflare et CapyDB place une configuration Hyperdrive devant votre cellule, la relie à votre projet Worker ou Pages et la maintient à jour. Les identifiants restent du côté de Cloudflare : les faire tourner atteint votre Worker sans redéploiement.
  • -Les origines Hyperdrive pointent vers l’endpoint du pooler avec un budget de connexions calibré sur votre offre, plutôt que sur la valeur par défaut de Cloudflare - laquelle peut dépasser le quota de connexions entier d’une petite offre.
  • -Une resynchronisation ne change plus rien tant que rien n’a changé. Les rotations, restaurations et imports ne publient plus discrètement une nouvelle version de votre Worker.
  • -Une extension CapyDB pour Netlify : une seule clé d’API au niveau de l’équipe, une base de données choisie par site, et les chaînes de connexion résolues au moment du build. Rien d’autre qu’un indicateur d’activation n’atterrit dans les variables d’environnement de votre site.
  • -Les bases installées via le Vercel Marketplace peuvent être transférées entre comptes Vercel. La cellule, son stockage et ses chaînes de connexion suivent le projet : les déploiements continuent de fonctionner, et les clés d’API limitées au projet sont révoquées.
  • -Le site et le tableau de bord parlent désormais anglais, allemand, espagnol, français, japonais, coréen, portugais et chinois. Les URL anglaises n’ont pas bougé.
  • -Fenêtre de restauration à un instant donné corrigée dans la documentation : elle est de 7 jours, et non des ~30 annoncés sur la page de reprise après sinistre. La restauration n’a jamais utilisé que des points de contrôle de stockage, donc 7 jours a toujours été la vraie réponse.

TLS vérifié, previews à chaud et benchmarks publiés

  • -Les chaînes de connexion utilisent désormais sslmode=verify-full face au certificat racine CapyDB, et les projets existants ont été mis à jour sur place - une connexion ne peut plus être interceptée en silence.
  • -Publication d’une page de benchmarks avec la méthodologie complète et les percentiles exacts, mesurés sur des nœuds de production et à travers le même proxy TLS que celui de tous les projets.
  • -Les chiffres principaux : p95 sous la milliseconde pour une requête sur connexion chaude, 2 301 transactions par seconde à 32 clients, et 15 ms pour ouvrir une connexion poolée neuve et obtenir une réponse.
  • -Publication aussi du chiffre du voisin bruyant, que presque personne ne publie : avec une cellule voisine sous forte charge continue, une cellule a conservé 49 % de son débit en solo. C’est un partage proportionnel, honnêtement mesuré, plutôt qu’une promesse d’isolation jamais vérifiée.
  • -Ouverture du code de capybench, le banc d’essai derrière ces chiffres, pour que chacun puisse les refaire contre nous ou contre d’autres.
  • -Les bases de preview démarrent à chaud : une preview dérive du stockage de sa cellule parente, si bien que son tout premier parcours de table complet a pris 255 ms, aussi vite qu’un parcours chaud sur la parente.
  • -Les cellules en pause reviennent plus vite : le réveil est anticipé à partir du trafic propre à la cellule, et un parcours massif ponctuel ne chasse plus l’ensemble de travail du cache.
  • -Paquets clients rafraîchis : @capydb/sdk 1.5.0, @capydb/mcp 1.4.1 et @capydb/drizzle 1.6.0.

Postgres 18, à part entière

  • -capydb.uuidv7() existe désormais sur chaque cellule et se résout vers la bonne implémentation sur Postgres 16, 17 et 18 : une valeur par défaut d’UUID triable dans le temps survit ainsi à une montée de version majeure au lieu de casser de l’autre côté.
  • -Les cellules Postgres 18 utilisent les nouvelles E/S asynchrones dimensionnées selon leur formule, et les vues de progression du vacuum de cette version sont consultables.
  • -Publication d’un guide Postgres 18 : UUID triables dans le temps, contraintes temporelles, colonnes générées virtuelles et renvoi de l’ancienne ligne - et comment s’en servir sans clouer un schéma à une seule version majeure.
  • -capydb doctor gagne des règles pour les choix de schéma qui coûtent le plus cher plus tard : valeurs par défaut uuidv7() non portables et colonnes nullables qui ne devraient pas l’être.
  • -Les colonnes générées apparaissent désormais dans l’introspection de schéma et dans capydb generate, pour que les types générés correspondent à la base.
  • -Les connexions poolées parlent le protocole réseau de Postgres 18.

Conseiller d’index et conversion des RLS Supabase

  • -Ajout d’un conseiller d’index qui propose des index à partir des requêtes que votre base a réellement exécutées, classés par ce qu’ils feraient gagner.
  • -Chaque candidat est mesuré comme index hypothétique - rien n’est créé, rien n’est écrit - donc le conseiller se lance sans danger sur la production.
  • -Le conseiller est dans le tableau de bord, dans capydb advisor indexes, dans l’API et comme outil MCP pour les agents.
  • -Ajout de capydb migrate rls, qui convertit les politiques de row-level security Supabase vers du Postgres nu et indique précisément quels claims votre application doit désormais fournir.
  • -Ouverture du code de capyrls, le convertisseur qui fait le travail.
  • -Ajout d’une page de schéma au tableau de bord pour parcourir tables, colonnes, index et enums de la base en fonctionnement.
  • -@capydb/drizzle gagne withAuthContext, une façon compatible avec le pooler d’exécuter des requêtes sous une identité de row-level security.
  • -Les notifications d’alerte partent aussi vers l’adresse de facturation de l’organisation, en plus du tableau de bord et de vos webhooks.

Montées de version, livraisons de webhooks et audit du dépôt

  • -Les montées de version mineures de Postgres sont à votre main : une cellule en pause en prend une gratuitement à son prochain réveil, une cellule active signale la version en attente et redémarre quand vous le décidez.
  • -Ajout d’un contrôle de préparation à une version majeure qui signale les bloquants avant que quoi que ce soit ne soit construit, pour qu’une montée majeure n’échoue pas à mi-parcours.
  • -Documentation du déroulé réel d’une montée majeure ici : copie complète avec fenêtre de vérification, bascule que vous confirmez, et retour arrière encore disponible ensuite.
  • -Les endpoints de webhook conservent désormais un historique de livraison avec le statut de chaque tentative, et une livraison peut être rejouée.
  • -Ajout de capydb webhooks test pour envoyer un événement de test signé à un endpoint.
  • -Ajout de capydb doctor, qui lit un dépôt et signale la configuration de base de données qui fait mal plus tard : fichiers .env pointant une même variable vers deux bases différentes, outils de migration mélangés de façon risquée, et pilotes braqués sur le mauvais port.

Postgres 16-18, connexions poolées et une vague d’outils pour développeurs

  • -Choix de la version majeure de Postgres : créez vos projets sur Postgres 16, 17 ou 18.
  • -Pooling de connexions par projet sur le port 6432, avec des tailles de pool adaptées à votre offre.
  • -Introspection de schéma et génération de types : capydb generate produit des définitions TypeScript, Zod ou Drizzle directement depuis votre schéma en production.
  • -Publication de @capydb/drizzle, une configuration Drizzle ORM aux réglages compatibles pooler pour les connexions CapyDB.
  • -Imports à interruption quasi nulle avec capydb import --follow, qui continue de répliquer les changements de votre ancienne base jusqu’à la bascule.
  • -Rotation des identifiants sans interruption : les anciens identifiants restent valides pendant une période de grâce, le temps de déployer les nouveaux.
  • -Suivi des logs en direct et analyse des requêtes dans le tableau de bord et via capydb logs.
  • -Les extensions Postgres sont désormais mises à jour automatiquement, signalées comme mises à jour de plateforme dans le tableau de bord.

Mise en pause à l’inactivité, et confirmation avant le destructif

  • -Les cellules se mettent en pause quand plus personne ne les interroge et reviennent à la connexion suivante, en un tiers de seconde environ. Une base inactive cesse de coûter du calcul.
  • -Les états en pause et en reprise sont remontés partout - tableau de bord, API et CLI - pour qu’une base en reprise se lise comme une reprise et non comme une panne.
  • -Ajout de la restauration à un instant donné directement sur une base de production, derrière une confirmation explicite.
  • -Les opérations destructrices exigent désormais cette confirmation : un import qui écraserait des données, ou la suppression d’un projet de production, échoue sans elle au lieu de passer sans bruit.
  • -Ajout de pg_cron au catalogue d’extensions.
  • -Ajout d’un flux d’événements de projet et d’un historique des tâches, pour regarder une opération longue plutôt que l’interroger en boucle.

Un Postgres par cellule

  • -Chaque cellule tourne désormais comme son propre Postgres, avec son propre stockage et ses propres limites de CPU et de mémoire, au lieu de partager un serveur avec d’autres projets.
  • -Les limites de connexions et la mémoire viennent de votre formule, pas de ce que les voisins ont laissé.
  • -Previews et restaurations sont devenues des dérivations du stockage d’une cellule, d’où leur création rapide quelle que soit la quantité de données derrière.
  • -Une nouvelle cellule n’est placée que sur un nœud qui a la marge pour la servir, et les limites par cellule empêchent la pointe d’un voisin de prendre le nœud entier.
  • -Tableau de bord, API, CLI et fournisseur Terraform parlent depuis lors le même vocabulaire : des cellules, sur des nœuds, dans des régions.

Extensions, alertes d’usage et une vague d’outils plateforme

  • -Tableau de bord repensé : barre latérale contextuelle au projet et check-list d’intégration sur chaque nouveau projet.
  • -Gestion des extensions Postgres : activez PostGIS, pgcrypto et d’autres extensions sélectionnées par projet, depuis le tableau de bord.
  • -Alertes de seuil sur le stockage et les connexions, transmises dans le tableau de bord, par webhook (alert.triggered / alert.resolved) et par e-mail.
  • -Lancement d’une page d’état en direct avec la santé par région.
  • -CLI enrichie d’une nouvelle série de commandes pour l’exploitation courante.
  • -Publication de @capydb/mcp, pour que les agents IA gèrent projets, previews et sauvegardes via MCP.
  • -Publication d’un provider Terraform pour la gestion déclarative des projets et des previews.
  • -Renforcement de la GitHub Action créant une base de preview par pull request.
  • -Nouvelle documentation sur le pooling, la reprise après sinistre, les bascules, la conformité et llms.txt.

Clés d’API, webhooks et intégrations fournisseurs

  • -Ajout de clés d’API à portée limitée, avec droits par clé, listing et révocation.
  • -Ajout d’endpoints de webhook avec événements signés pour le cycle de vie des projets et des tâches, chacun avec son secret et sa rotation.
  • -Ajout d’intégrations Vercel et Netlify qui poussent les chaînes de connexion dans l’environnement de votre projet et les repoussent après rotation, restauration et import.
  • -Ajout d’intégrations de synchronisation d’utilisateurs pour Clerk, Auth0 et Better Auth.

Rafraîchissement de la marque et du marketing

  • -Repositionnement du site public autour d’un Postgres infogéré sans esbroufe.
  • -Réécriture des textes tarifs, à propos, contact, docs et blog avec une voix plus nette, tournée vers celles et ceux qui construisent.
  • -Message aligné sur les bases jetables, l’accès direct et des limites produit assumées.

Authentification d’organisation via Clerk dans le tableau de bord

  • -Vérification des jetons de session Clerk côté backend.
  • -Correspondance des organisations Clerk actives avec les organisations CapyDB dans les métadonnées.
  • -Le jeton admin global n’est plus requis côté frontend pour les routes normales du tableau de bord.

Interface d’administration et réglages d’organisation

  • -Interface d’administration pour lister et créer organisations et nœuds de la grille.
  • -Bascule entre plusieurs organisations via le composant OrganizationSwitcher de Clerk.
  • -Édition des métadonnées de facturation, gestion d’équipe et révocation des clés d’API dans les réglages.

Nettoyage du site public

  • -Remplacement des routes provisoires docs, blog, mentions légales, à propos, contact et journal des modifications par du contenu réel.
  • -Suppression des références à des fonctions CLI non livrées et aux mentions « bientôt disponible ».