Bases de données gérées

Une base de données gérée, c'est PostgreSQL, MySQL (Percona Server), MariaDB ou Valkey (compatible Redis) exploité par FFxF dans l'un de vos réseaux privés : sauvegardée en continu, restaurable à la minute près sur les 7 derniers jours, mise à jour dans un créneau que vous choisissez, avec un certificat reconnu partout. Vous recevez une chaîne de connexion ; FFxF fait tourner le moteur, le système et les sauvegardes. Les bases gérées sont en bêta, ouvertes à tous les comptes.

Créer une base

bash

curl -s https://api.ffxf.net/v1/databases/options -H "Authorization: Bearer $FFXF_TOKEN"

curl -s -X POST https://api.ffxf.net/v1/databases \
     -H "Authorization: Bearer $FFXF_TOKEN" \
     -H "Idempotency-Key: $(uuidgen)" \
     -H "Content-Type: application/json" \
     -d '{"name": "commandes", "vpc": 12, "size_gb": 1}'

json

{ "data": { "id": 7, "name": "commandes", "status": "pending", "engine": "postgresql", "version": "18", "region": "montreal", "size_gb": 1,
  "connection": { "host": "private-k3v9x2m1qa.db.ffxf.cloud", "port": 5432, "database": "defaultdb", "username": "ffxfadmin", "ssl_mode": "verify-full" } } }

"engine" choisit postgresql (par défaut), mysql, mariadb ou valkey ; GET /databases/options donne leurs versions, les tailles avec leur prix à l'heure (le même pour tous les moteurs) et les extensions. La facturation commence tout de suite, à l'heure, comme une machine : le compte doit couvrir 24 heures. La base est prête en quelques minutes, quand status passe de pending à active. Elle arrive avec un utilisateur administrateur, ffxfadmin, et une base logique, defaultdb (Valkey : l'administrateur default, et pas de base logique).

Moteurs

Moteur	Versions	Port	TLS, côté client
PostgreSQL	18, 17	5432	`sslmode=verify-full&sslrootcert=system`
MySQL (Percona Server)	8.4	3306	`--ssl-mode=VERIFY_IDENTITY`
MariaDB	11.8	3306	`--ssl-verify-server-cert`
Valkey (compatible Redis)	8.1	6379	`rediss://`, ou `--tls` pour `valkey-cli` et `redis-cli`

Tous les moteurs ont les mêmes sauvegardes, forks, accès public, créneau de maintenance et disque. Les sauvegardes diffèrent pour Valkey (instantanés horaires, plus bas) ; les utilisateurs et les bases logiques, pour MySQL, MariaDB et Valkey.

Se connecter

bash

curl -s https://api.ffxf.net/v1/databases/7/credentials -H "Authorization: Bearer $FFXF_TOKEN"

json

{ "data": { "users": [ { "username": "ffxfadmin", "admin": true, "password": "…", "connection_uri": "postgresql://ffxfadmin:…@private-k3v9x2m1qa.db.ffxf.cloud:5432/defaultdb?sslmode=verify-full&sslrootcert=system" } ],
  "connection_uri": "postgresql://ffxfadmin:…@private-k3v9x2m1qa.db.ffxf.cloud:5432/defaultdb?sslmode=verify-full&sslrootcert=system",
  "public_connection_uri": null } }

Les machines du réseau privé joignent la base à connection.host, sur le port du moteur. Le TLS est toujours exigé, avec un certificat Let's Encrypt renouvelé pour vous : sslmode=verify-full vérifie le certificat et le nom. sslrootcert=system demande libpq 16 ou plus récent ; avec un client plus ancien, faites pointer sslrootcert vers le magasin du système (/etc/ssl/certs/ca-certificates.crt sous Debian et Ubuntu).

bash

mysql --host=private-k3v9x2m1qa.db.ffxf.cloud --user=ffxfadmin -p --ssl-mode=VERIFY_IDENTITY defaultdb

valkey-cli -u "rediss://default:$VALKEY_PASSWORD@private-k3v9x2m1qa.db.ffxf.cloud:6379" PING

Les mots de passe ne sortent que par GET …/credentials et par les appels qui en créent un, avec la portée databases.write : une clé de supervision en vms.read voit la base mais ne peut pas s'y connecter. Donnez la chaîne de connexion à votre application par une variable d'environnement ou un coffre à secrets, jamais dans le code.

Utilisateurs, bases et extensions

bash

curl -s -X POST https://api.ffxf.net/v1/databases/7/users \
     -H "Authorization: Bearer $FFXF_TOKEN" -H "Content-Type: application/json" \
     -d '{"username": "app"}'

curl -s -X POST https://api.ffxf.net/v1/databases/7/databases/defaultdb/extensions \
     -H "Authorization: Bearer $FFXF_TOKEN" -H "Content-Type: application/json" \
     -d '{"extension": "vector"}'

Un nouvel utilisateur reçoit un mot de passe généré, rendu une fois par l'appel (et relisible ensuite par …/credentials) ; il est actif en quelques secondes. Les noms sont en minuscules, chiffres et _ ; jusqu'à 30 utilisateurs et 30 bases logiques. L'administrateur n'est pas superutilisateur, mais possède les bases logiques. Depuis PostgreSQL 15, un nouvel utilisateur ne peut pas créer de tables dans le schéma public tant que l'administrateur ne le lui permet pas :

sql

GRANT CREATE ON SCHEMA public TO app;

Les extensions viennent d'une liste : vector (pgvector), postgis, pg_trgm, pgcrypto, uuid-ossp, hstore, citext, unaccent, ltree et quelques autres, toutes données par GET /databases/options. Le retrait ne se propage pas : si des objets en dépendent encore, l'extension reste et le warning de la base dit pourquoi.

MySQL et MariaDB

Les utilisateurs et les bases logiques se créent par l'API ou la console, pas en SQL. Chaque utilisateur a tous les droits dans chaque base logique, et l'administrateur peut les transmettre (GRANT). L'administrateur n'a ni SUPER, ni FILE, ni CREATE USER, ni droit sur le schéma mysql. Pas d'extensions. Les requêtes lentes viennent de performance_schema, valeurs remplacées par ?, sans l'utilisateur.

Valkey

L'administrateur est default : un client qui n'envoie qu'un mot de passe (AUTH <mot de passe>, rediss://:<mot de passe>@…) s'y connecte. Les autres utilisateurs sont des utilisateurs ACL : toutes les clés, tous les canaux et toutes les commandes de données, y compris KEYS, FLUSHALL, SORT, INFO et CONFIG GET. Les commandes du serveur (CONFIG SET, ACL, SAVE, SHUTDOWN, MODULE, MONITOR…) sont refusées. Rien à créer côté bases : les 16 bases numérotées (SELECT 0 à 15) sont ouvertes à chaque utilisateur.

bash

curl -s -X PATCH https://api.ffxf.net/v1/databases/9 \
     -H "Authorization: Bearer $FFXF_TOKEN" -H "Content-Type: application/json" \
     -d '{"eviction_policy": "allkeys-lru"}'

Environ 60 % de la taille reçoit les données (data_memory.max_bytes) ; le reste fait tourner le système et les instantanés. eviction_policy dit ce qui se passe quand elle est pleine : noeviction, par défaut, refuse les écritures et garde tout ; allkeys-lru retire les clés les moins utilisées, pour un cache ; les politiques volatile-* ne retirent que les clés qui expirent. Chaque écriture est sur disque dans la seconde. Hors site, un instantané est pris chaque heure s'il y a eu des écritures : tous sont gardés 24 heures, puis un par jour sur 7 jours. Une restauration ramène le dernier instantané pris avant la minute choisie. Les requêtes lentes sont les commandes qui prennent le plus de temps depuis le démarrage du moteur, et les statistiques comptent des commandes plutôt que des transactions.

Sauvegardes et restauration

Les sauvegardes sont automatiques et incluses : une complète chaque semaine, une différentielle chaque jour, et le journal des transactions archivé en continu. Elles sont chiffrées avant de quitter la base et gardées 7 jours, hors du serveur qui la fait tourner. Chaque semaine, la dernière complète est restaurée pour essai et vérifiée (backups.last_restore_test).

bash

curl -s -X POST https://api.ffxf.net/v1/databases/7/restore \
     -H "Authorization: Bearer $FFXF_TOKEN" \
     -H "Idempotency-Key: $(uuidgen)" \
     -H "Content-Type: application/json" \
     -d '{"at": "2026-10-14T09:30:00Z", "name": "commandes-avant-migration"}'

Une restauration n'écrase jamais rien : elle crée une nouvelle base, facturée comme les autres, avec les données telles qu'elles étaient à cette minute, les mêmes utilisateurs et les mêmes mots de passe. N'importe quelle minute de backups.restore_window convient (GET …/backups). Une base supprimée garde ses sauvegardes 7 jours : elle se restaure encore de cette façon. Avant une migration risquée, POST …/backups lance une sauvegarde sur-le-champ.

Forks

bash

curl -s -X POST https://api.ffxf.net/v1/databases/7/forks \
     -H "Authorization: Bearer $FFXF_TOKEN" \
     -H "Idempotency-Key: $(uuidgen)" \
     -H "Content-Type: application/json" \
     -d '{"name": "commandes-preprod"}'

Un fork est une nouvelle base dont les données sont une copie instantanée de la source, quelle que soit sa taille : une préproduction, l'essai d'une migration, une analyse qui ne doit pas charger la production. Il naît lié à sa source : pas de sauvegardes à lui, et la source ne peut pas être supprimée. Au bout de 7 jours, ou avec POST …/detach, il reçoit sa propre copie des données (une trentaine de secondes de coupure) et ses sauvegardes commencent.

Changer de taille

bash

curl -s -X POST https://api.ffxf.net/v1/databases/7/resize \
     -H "Authorization: Bearer $FFXF_TOKEN" \
     -H "Idempotency-Key: $(uuidgen)" \
     -H "Content-Type: application/json" \
     -d '{"size_gb": 2}'

Passe la base à une taille supérieure parmi celles de GET /databases/options : plus de vCPU, de mémoire et de disque inclus. Les données, les utilisateurs, les noms et les adresses ne changent pas. La base redémarre : une à deux minutes de coupure, pendant lesquelles status vaut maintenance et resize.to_gb la taille demandée ; elle revient ensuite active avec son nouveau size_gb. Les réglages du moteur qui dépendent de la mémoire (tampons de PostgreSQL, tampon InnoDB, mémoire des données de Valkey) suivent. Le nouveau tarif s'applique à partir de l'heure suivante. Taille supérieure seulement : le disque ne rétrécit pas. Aussi dans la console, onglet Réglages.

Accès public

bash

curl -s -X PUT https://api.ffxf.net/v1/databases/7/public-access \
     -H "Authorization: Bearer $FFXF_TOKEN" -H "Content-Type: application/json" \
     -d '{"enabled": true, "sources": ["203.0.113.10", "2001:db8::/48"]}'

Coupé à la création. Ouvert, la base répond aussi à public_access.host sur son propre port (gardé toute sa vie), en IPv4 et en IPv6, TLS et mot de passe toujours exigés. sources limite qui peut se connecter ; absent, rien ne change ; null ou vide, tout le monde entre. Les changements s'appliquent en une trentaine de secondes. Préférez le réseau privé dès que le client tourne chez FFxF.

Au quotidien

Action	Appel	Bon à savoir
Statistiques	`GET /databases/{id}/metrics?range=24h`	CPU, mémoire, connexions et transactions par minute ; `1h`, `24h` ou `7d`, gardées 7 jours.
Requêtes lentes	`GET /databases/{id}/queries`	Les 20 requêtes qui prennent le plus de temps au total, normalisées (`$1`, `$2`… ou `?`) ; sur Valkey, par commande.
Éviction (Valkey)	`PATCH /databases/{id}` avec `eviction_policy`	Appliquée en quelques secondes ; `noeviction` par défaut.
Créneau de maintenance	`PATCH /databases/{id}` avec `maintenance_day` et `maintenance_hour`	Le dimanche à 3 h, heure de Montréal, par défaut, pendant 2 heures. Les mises à jour mineures passent alors, en général avec une minute ou deux de coupure.
Disque	`PATCH /databases/{id}` avec `disk_cap_gb`	Le disque grandit seul à 80 % de remplissage, jusqu'au plafond. Au plafond, un courriel vous prévient ; presque plein, la base passe en lecture seule jusqu'à ce que le plafond monte ou que des données partent.
Taille	`POST /databases/{id}/resize` avec `size_gb`	Taille supérieure seulement ; une à deux minutes de coupure, nouveau tarif dès l'heure suivante.
Supprimer	`DELETE /databases/{id}`	La facturation s'arrête ; les sauvegardes restent 7 jours. Refusé tant qu'un fork lié en dépend.

Limites et facturation

Trois bases par compte par défaut, davantage sur demande depuis la console. Une base est facturée à l'heure selon sa taille ; le disque au-delà de celui que la taille inclut coûte 0,15 CAD par Go et par mois, facturé à l'heure lui aussi. Les sauvegardes, les restaurations, l'essai de restauration hebdomadaire et l'accès public sont inclus.

Détails utiles

Lire demande vms.read (sans mot de passe) ; créer, restaurer, forker et changer de taille demandent vms.create et une Idempotency-Key ; supprimer demande vms.destroy ; rendre un fork indépendant, vms.action ; une sauvegarde à la demande, backups.write ; l'accès public, network.write. Les mots de passe, utilisateurs, bases logiques, extensions et réglages demandent databases.write. Le serveur MCP expose les mêmes actions : voir les outils MCP.