Présentation

Gnomon est une extension native pour PostgreSQL 15‑18 qui introduit le concept de branche de base de données au niveau du serveur. L’installation se résume à 

create extension gnomon;
et fonctionne sur des environnements auto‑hébergés ou gérés (RDS, Aurora, Supabase). Chaque branche se matérialise comme une simple chaîne de connexion ; aucune copie physique de la base n’est créée, ce qui permet d’ouvrir un branchement instantanément, même pour des jeux de données volumineux.

Mécanisme de branchement

Après avoir indiqué les tables à suivre (

select gnomon.track('orders');
), l’API expose 
select gnomon.create_branch('agent/refunds');
select gnomon.use('agent/refunds');
. Toutes les requêtes suivantes s’exécutent sur le contexte « agent/refunds », isolées du schéma principal. La branche lit les données du « main » et ne conserve que les modifications locales, ce qui évite toute duplication de fichiers. Les migrations de schéma sont également prises en charge : une colonne ajoutée sur une branche ne devient visible dans le principal qu’après un merge.

Gestion des conflits et historique

Gnomon fournit un diff détaillé (

select * from gnomon.diff('agent/refunds');
) qui liste chaque ligne et chaque champ modifié. Le merge s’effectue via un algorithme trois‑voies sensible aux types : les compteurs s’additionnent, les objets JSON sont fusionnés clé par clé, les textes sont fusionnés ligne par ligne. En cas de véritable collision, le système génère un conflit exploitable par l’opérateur ou résolvable par une requête personnalisée. L’historique complet de chaque table est conservé, permettant des requêtes temporelles comme 
select gnomon.use('main', '2026-10-31 23:59');
select sum(amount) from invoices where status = 'open';
. Le flux d’événements peut être acheminé vers Kafka, NATS ou un webhook, et intégré à dbt comme snapshots.

Intégration et performances

Les SDK TypeScript et Python exposent des primitives de haut niveau ; l’exemple suivant crée un run, applique une mise à jour et soumet le résultat : 

await using run = await gnomon.startRun({
  task: "Refund order 4182",
  actor: "support-bot",
});
await run.sql("update orders set status = 'refunded' where id = 4182");
const { checks, changes } = await run.summary();
if (checks.passed && changes.rows <= 20) await run.merge();
else await run.submit({ title: "Refund order 4182" });
. Les politiques de fusion (nombre maximal de lignes, tables autorisées, validation de checks) sont appliquées par PostgreSQL, garantissant que les agents ne peuvent pas dépasser les limites définies. La création d’un rôle dédié et d’une branche se fait en une commande (
gnomon agent create support-bot
), assurant une isolation complète entre les agents. Les benchmarks publiés dans la documentation indiquent un overhead négligeable pour la création de branche et une latence de merge proportionnelle au nombre de lignes modifiées, ce qui rend l’approche viable même pour des pipelines CI/CD intensifs.