À propos de CapyDB

Parce que la plupart de celles et ceux qui construisent n’ont pas besoin d’une plateforme backend complète, ni d’une API de base de données propriétaire, ni d’une toute nouvelle philosophie de l’infrastructure. Ils ont besoin de Postgres.

Nous avons donc réduit le Postgres infogéré à une seule primitive : la cellule de base de données – un runtime Postgres isolé avec son propre processus, son stockage, ses identifiants et ses limites CPU/RAM, dédié à un seul projet. L’API gère les cellules, vous utilisez des URL Postgres normales.

Tout le reste du produit, c’est le cycle de vie autour de cette primitive : provisionnement, connexions directes et via pooler, bases de preview, sauvegardes, imports, restaurations et extensions.

• -Les vibe codeurs qui transforment un projet du week-end en vraie application
• -Les bidouilleurs qui veulent une chaîne de connexion, pas une cérémonie
• -Les indie hackers et les petites équipes qui livrent vite
• -Les équipes qui veulent une base de données ennuyeuse et une stack bien à elles

• -L’isolation : chaque projet dans sa propre cellule – processus, identifiants, quota de stockage, CPU et mémoire
• -La simplicité : des connexions postgres:// standard et l’outillage habituel
• -La performance : accès direct et via pooler, avec un plan de contrôle léger
• -La fiabilité : sauvegardes vérifiées, restauration à un instant précis, previews jetables et flux de travail prévisibles

Pas un BaaS. Si vous voulez l’authentification, le stockage, les fonctions et tout le reste de la panoplie, prenez un produit conçu pour ça.

Pas non plus un moteur de stockage exotique réécrit. De vrais processus Postgres sur du vrai matériel, isolés par projet – l’effort d’ingénierie est passé à rendre une primitive excellente plutôt qu’à faire exister beaucoup de fonctionnalités.