Bases de données gérées à Montréal, en démonstration

Les bases de données gérées sont ouvertes à tous les comptes FFxF, en bêta : PostgreSQL 18 et 17, MySQL 8.4 (Percona Server), MariaDB 11.8 et Valkey 8.1, compatible Redis. La base vit dans votre réseau privé, à Montréal. Vous recevez une chaîne de connexion ; FFxF fait tourner le moteur, le système, les sauvegardes et les mises à jour.

Cet article suit une base de bout en bout, avec les sorties réelles d'une démonstration faite le 15 octobre 2026 : création, connexion depuis une machine du réseau privé, une erreur rattrapée à la minute près, un fork et un passage à la taille supérieure. Les heures sont celles de Montréal ; seuls les mots de passe sont masqués.

1. Ce qui est compris

• Un certificat reconnu (Let's Encrypt) pour le nom privé et le nom public de la base : le client vérifie le serveur, sans fichier à télécharger.
• Des sauvegardes chiffrées dans la VM avant de partir hors site, gardées 7 jours, et un essai de restauration chaque semaine.
• La restauration à la minute sur ces 7 jours, dans une nouvelle base : la base d'origine n'est jamais écrasée.
• Un disque qui grandit seul à 80 % de remplissage, jusqu'au plafond que vous fixez.
• Les mises à jour mineures dans un créneau de deux heures que vous choisissez.
• Le fork : une copie instantanée des données, quelle que soit leur taille.
• L'accès public, coupé à la création, que vous ouvrez au besoin et limitez à vos adresses.

2. Créer la base

Dans la console, la page Bases de données demande un moteur, une taille et un réseau privé. Le prix s'affiche à l'heure et au mois avant de valider :

La même chose par l'API, comme pour la démonstration :

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": "boutique", "vpc": 14, "engine": "postgresql", "size_gb": 1}'

La réponse arrive tout de suite, la base en préparation :

{
  "id": 19,
  "name": "boutique",
  "status": "pending",
  "engine": "postgresql",
  "version": "18",
  "size_gb": 1,
  "connection": {
    "host": "private-al7wfsqini.db.ffxf.cloud",
    "port": 5432,
    "database": "defaultdb",
    "username": "ffxfadmin",
    "ssl_mode": "verify-full"
  },
  "billing": {"mode": "hourly", "rate": "0.020", "currency": "CAD"}
}

Ce qui s'est passé ensuite, d'après le journal de la démonstration :

Un peu plus de cinq minutes pour la base, la première sauvegarde et son essai de restauration, puis moins d'une minute pour le certificat.

3. Se connecter depuis le réseau privé

La connexion part d'une petite VM Debian 13 placée dans le même réseau privé. La chaîne de connexion vient de la console ou de GET /v1/databases/19/credentials :

$ psql "postgresql://ffxfadmin:••••••••@private-al7wfsqini.db.ffxf.cloud:5432/defaultdb?sslmode=verify-full&sslrootcert=system" \
    -c 'SELECT version();' \
    -c 'SELECT ssl, version AS tls FROM pg_stat_ssl WHERE pid = pg_backend_pid();'
 PostgreSQL 18.6 (Debian 18.6-1.pgdg13+2) on x86_64-pc-linux-gnu, compiled by gcc (Debian 14.2.0-19) 14.2.0, 64-bit

 ssl |   tls
-----+---------
 t   | TLSv1.3

sslmode=verify-full vérifie que le certificat est valable et qu'il porte bien le nom de la base ; sslrootcert=system fait confiance aux autorités du système (libpq 16 ou plus récent). Le certificat présenté :

subject=CN=al7wfsqini.db.ffxf.cloud
issuer=C=US, O=Let's Encrypt, CN=YR2
Verify return code: 0 (ok)

MySQL et MariaDB s'utilisent de la même façon avec ssl-mode=VERIFY_IDENTITY, Valkey avec une adresse rediss://.

4. Une erreur, rattrapée à la minute près

L'application de la démonstration enregistre 5 000 commandes :

CREATE TABLE commandes (
  id serial PRIMARY KEY,
  client text NOT NULL,
  total numeric(10,2) NOT NULL,
  passee_le timestamptz NOT NULL DEFAULT now()
);
INSERT INTO commandes (client, total)
  SELECT 'client-' || n, round((random() * 200)::numeric, 2) FROM generate_series(1, 5000) AS n;

 count |    sum
-------+-----------
  5000 | 499112.79      -- 12:37:57

Une minute plus tard, une requête oublie son WHERE :

DELETE FROM commandes;   -- 12:39:20
DELETE 5000

L'onglet Sauvegardes montre la fenêtre de restauration. Elle couvre déjà l'instant voulu : 12:38, entre l'enregistrement des commandes et l'erreur.

Par l'API, l'instant se donne en UTC :

curl -s -X POST https://api.ffxf.net/v1/databases/19/restore \
     -H "Authorization: Bearer $FFXF_TOKEN" \
     -H "Idempotency-Key: $(uuidgen)" \
     -H "Content-Type: application/json" \
     -d '{"at": "2026-10-15T16:38:30Z", "name": "boutique-avant-erreur"}'

Demandée à 12:40:36, la base restaurée était active à 12:46:58, et son certificat en place 23 secondes plus tard. L'essentiel de ces six minutes sert à préparer la nouvelle VM ; la restauration des données elle-même a pris 12 secondes. Les commandes sont toutes là :

SELECT count(*), sum(total), max(passee_le) FROM commandes;

 count |    sum    |              max
-------+-----------+-------------------------------
  5000 | 499112.79 | 2026-10-15 16:37:57.855193+00

La base d'origine, elle, n'a pas été touchée : elle contient toujours 0 commande. Vous pouvez y relire ce qui s'est passé avant de la supprimer.

5. Un fork pour la préproduction

Un fork est une nouvelle base dont les données sont une copie instantanée d'une autre :

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

Les données étaient copiées moins de 30 secondes après la demande, et le fork actif à 12:53:28, le temps de démarrer sa VM. Mêmes 5 000 commandes ; une modification sur le fork ne change rien à la source :

-- sur le fork
UPDATE commandes SET total = 0 WHERE id <= 100;
UPDATE 100

-- sur la source
SELECT count(*) FILTER (WHERE total = 0) AS remises_a_zero, sum(total) FROM commandes;
 remises_a_zero |    sum
----------------+-----------
              0 | 499112.79

Le fork reste lié à sa source pendant 7 jours au plus, sans sauvegardes à lui, puis reçoit sa propre copie et ses sauvegardes.

6. Passer à la taille supérieure

La base restaurée devient la nouvelle production ; elle passe à 2 Go, depuis l'onglet Réglages ou par l'API :

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

Demandé à 12:54:38. Le moteur s'arrête proprement, la VM redémarre avec ses nouvelles ressources (12:54:56), puis les réglages qui dépendent de la mémoire sont recalculés. Pendant ce temps, une sonde lançait une requête toutes les deux secondes depuis la VM cliente : la première réponse après la coupure est arrivée à 12:55:06, soit moins de 30 secondes sans base. Le redémarrage du moteur qui applique les nouveaux réglages, ensuite, n'a fait échouer aucune requête.

                  avant    après
shared_buffers    241MB    493MB
max_connections   25       50
commandes         5000     5000

Le disque inclus passe de 10 à 30 Go. Le nouveau tarif, 0,030 CAD l'heure, s'applique à partir de l'heure suivante : l'heure en cours est déjà payée. Il n'y a pas de retour à une taille inférieure, parce que le disque ne rétrécit pas.

7. Depuis un agent IA

Le serveur MCP FFxF expose les mêmes actions : create_database, get_database_credentials, restore_database, fork_database, resize_database. Ses consignes demandent à l'agent d'annoncer le prix avant de créer ou d'agrandir une base, et de vous demander votre accord avant d'en supprimer une. Les mots de passe ne sortent que sous la portée databases.write : une clé qui surveille (vms.read) voit les bases, pas de quoi s'y connecter.

8. Prix

Facturé à l'heure, sur votre crédit, comme une machine. Les sauvegardes, la restauration, les essais de restauration et l'accès public sont compris ; le disque au-delà de celui que la taille inclut coûte 0,15 CAD par Go et par mois. La démonstration complète (trois bases et une petite VM pendant moins d'une heure) a coûté moins de 10 cents.

Checklist

• La base dans le même réseau privé que les machines qui s'en servent.
• sslmode=verify-full (ou ssl-mode=VERIFY_IDENTITY) dans la chaîne de connexion de l'application.
• Le mot de passe dans une variable d'environnement ou un coffre à secrets, jamais dans le dépôt.
• Un créneau de maintenance à une heure creuse pour votre application.
• Un plafond de disque qui laisse de la marge.
• Avant une migration risquée : une sauvegarde à la demande, ou un fork pour l'essayer d'abord.

Moteurs, réglages, accès public et toutes les routes de l'API sont dans le guide des bases de données.