Base de données serverless, privée et hébergée en France
Chaque compte peut provisionner sa propre base de données SQL. Elle vit dans votre espace isolé, se met en veille avec vos fonctions, et seules les fonctions de votre compte peuvent y accéder.
Ce que vous obtenez
Une base par compte, provisionnée en une requête depuis l'interface, l'API ou un agent IA. Vous obtenez un moteur SQL complet (tables, index, transactions, requêtes standard), pas un magasin clé-valeur bridé.
Sous le capot, c'est libSQL, un dérivé de SQLite conçu pour être interrogé en réseau. Vos fonctions s'y connectent en HTTP, et c'est justement ce qui permet à la base de s'endormir puis de se réveiller à la demande ; une connexion permanente l'en empêcherait.
- Le schéma reste le vôtre : vous désignez une de vos fonctions comme migrateur et vous la déclenchez quand vous le décidez.
- Un palier de stockage ferme, choisi à la création, augmentable à tout moment.
- Les données sont répliquées en continu vers un stockage objet : c'est lui la référence, pas le disque de l'instance.
- Rien à installer : les clients libSQL sont déjà présents dans les environnements Python et Node.js.
Elle dort avec vos fonctions
Sans requête pendant la durée d'inactivité configurée (10m par défaut, réglable de 6 secondes à 1 heure), l'instance s'arrête. Vous ne payez plus aucun temps de calcul ; seul le palier de stockage réservé reste facturé, puisque vos données, elles, restent bien là.
La requête suivante réveille la base automatiquement, en quelques secondes de démarrage, restauration comprise. Allonger la durée d'inactivité évite de repayer ce réveil entre deux requêtes espacées, pour une fraction du coût d'une instance permanente.
Si vous préférez une latence toujours constante, le mode « toujours active » maintient une instance en permanence, au prix du calcul correspondant. Les deux réglages se changent à tout moment, sans jamais déplacer les données.
Qui peut y accéder
La vraie question est : qui peut lire vos données ? Uniquement les fonctions de votre compte auxquelles vous avez explicitement attaché la base. Voici ce qui le garantit, mécanisme par mécanisme.
- Aucune adresse publique. La base n'est pas exposée sur Internet. Elle ne possède qu'une adresse interne au cluster, injectée dans vos fonctions, et il n'existe pas d'URL à taper dans un navigateur.
- Un espace cloisonné. Votre compte dispose de son propre espace Kubernetes, avec une politique réseau qui refuse tout par défaut : les pods d'un autre compte n'ont aucune route vers le vôtre.
- Un jeton propre à VOTRE base. L'accès exige un jeton signé, dérivé de l'identifiant de cette base précise. Le jeton d'une autre base ne l'ouvre pas : elle répond « non autorisé ». Nous le vérifions en conditions réelles à chaque livraison.
- Un jeton que personne ne lit. Il n'est renvoyé par aucune API, aucune page de l'interface, aucun outil destiné aux agents IA. Il est monté depuis un secret en écriture seule, et uniquement dans les fonctions que vous attachez.
- Des identifiants de stockage qui ne circulent pas. Les clés d'accès au stockage objet restent dans le serveur de base : vos propres fonctions ne les voient jamais, et un agent IA pilotant votre compte non plus.
Le retrait d'un accès est tout aussi explicite : détachez la fonction, et elle perd la variable d'environnement au redémarrage. En cas de doute sur une fuite, faites tourner le jeton de la base ; l'ancien cesse d'être accepté et les fonctions attachées reçoivent le nouveau.
Sauvegarde, export et rétention
Vous pouvez générer à tout moment un export SQL de votre base : un fichier compressé, téléchargeable pendant 24 heures via un lien signé, et restaurable n'importe où avec l'outil sqlite3 standard. Aucun logiciel de notre part n'est nécessaire pour le relire, c'est du SQL ordinaire.
Le service est en bêta : conservez vos propres sauvegardes. Si le solde de votre compte reste à zéro, les données sont conservées 7 jours, puis supprimées définitivement ; recharger avant l'échéance annule la suppression. Supprimer une base efface également ses données du stockage objet, tandis que vos exports déjà générés, eux, sont conservés.
Ce que ça coûte
Deux axes, tous les deux à l'usage. L'instance de la base est facturée au même tarif de calcul qu'une fonction de même taille, et rien du tout pendant son sommeil. Le palier de stockage que vous détenez est facturé 0,40 € par Go et par mois, au prorata, que la base soit réveillée ou non : les octets occupent de la place dans les deux cas.
Le palier peut être augmenté à tout moment et prend effet au redémarrage suivant. Il ne peut pas être réduit.
Mes données survivent-elles à la mise en veille ?
Oui. La référence n'est pas le disque de l'instance mais le stockage objet, alimenté en continu. Quand la base se rendort puis se réveille, elle repart de cet état, et c'est exactement ce que l'exemple d'inventaire de notre documentation démontre en direct.
Une autre personne peut-elle lire ma base de données ?
Non. La base n'a pas d'adresse publique, elle vit dans l'espace cloisonné de votre compte, et l'accès exige un jeton signé dérivé de l'identifiant de cette base précise : un jeton appartenant à une autre base est refusé. Seules les fonctions de votre compte que vous avez attachées reçoivent ce jeton, et il n'est affiché nulle part.
Puis-je récupérer mes données si je pars ?
Oui, à tout moment et sans nous le demander : l'export produit un fichier SQL standard que vous restaurez avec sqlite3, sur votre machine ou chez n'importe quel autre hébergeur. Il n'y a pas de format propriétaire à déchiffrer.
Un agent IA connecté à mon compte peut-il gérer la base ?
Oui, et sans jamais voir vos identifiants. Un agent peut créer la base, l'attacher à une fonction, lancer vos migrations, changer le palier ou déclencher un export. Le jeton d'accès et les clés du stockage, eux, ne lui sont jamais transmis.