Jepsen : 96 défauts dans ParticleDB, à quitter

Ce qui se passe

ParticleDB, écrite en Rust par Orkes, se présente comme une base transactionnelle, clé-valeur, vectorielle et analytique pour les agents d'IA, compatible avec le protocole Postgres. Son site annonçait du « Full ACID » et une preuve TLA+ jamais publiée.

Jepsen a testé les versions 1.1.4 à 1.1.18.11.rc-22 et a relevé 96 problèmes. La plupart apparaissent avec un seul nœud, un seul client et aucune panne provoquée. Quelques cas :

• WHERE 4 = 5 renvoyait la ligne de clé primaire 5, et WHERE TRUE ne renvoyait rien ;
• NOT NULL et UNIQUE n'empêchaient rien, et une clé primaire pouvait être dupliquée ou nulle ;
• une table supprimée pouvait réapparaître sous une forme altérée ;
• des transactions annulées pouvaient être validées.

Ce qu'il reste

En rc-22, tous les problèmes sauf dix semblaient résolus. Mais :

• le mode par défaut occ perdait encore des écritures validées en fonctionnement normal : sur un test en occ-v3 avec WAL sync, 31 clés sur environ 20 000 ;
• serializable, le réglage le plus strict, laissait passer des lectures périmées et, en cas d'arrêt brutal du processus, des anomalies internes et des Lost Update ;
• un WAL corrompu entraînait une perte partielle, et des lectures ou écritures mal dirigées, simulées, pouvaient tout faire perdre.

Jepsen recommande de stopper les nouveaux déploiements, de migrer dès que possible, et de vérifier ou reconstruire les données depuis une source plus fiable si elle existe.

Les réserves

• Le travail est financé par Orkes, selon la politique éthique de Jepsen.
• Seul le nœud unique est couvert : la réplication n'a pas été testée.
• Orkes affirme que la 1.1.19-rc.13 corrige tout. Jepsen ne l'a pas évaluée.
• Orkes estime que sa version de production, la 1.0.0, n'est pas touchée. Un rapide essai de Jepsen n'y a pas retrouvé la plupart des erreurs graves, mais cela reste un essai sommaire.
• Les versions 1.1.x étaient proposées au téléchargement de mai à juillet 2026, sans mention de préversion à l'époque, et décrites depuis comme des préversions non prises en charge.

La méthode à emprunter

Le test compare tient en deux mille lignes environ : il génère schémas et requêtes au hasard, les exécute sur ParticleDB et sur Postgres, puis compare les résultats. Jepsen en a extrait une partie dans une bibliothèque réutilisable.

Sa limite : une fois les gros défauts corrigés, de petites différences légitimes occupent le test, qui risque de manquer le reste.

Jepsen s'interroge enfin sur le rôle des LLM : une documentation abondante citant des classes qui n'existent pas, et une équipe qui, selon le rapport, semblait ne pas pouvoir expliquer la plupart des causes. Rien ne prouve ce lien pour chaque défaut, mais les signes de maturité ne suffisent plus à juger un projet.

Comment s'y prendre

1. Si vous utilisez ParticleDB 1.1.x, suivez la recommandation et contrôlez vos données.
2. Avant d'adopter une base récente, rejouez vos requêtes contre Postgres, en insérant des cas limites : NULL, doublons, NaN, transactions annulées.
3. Ne prenez pas « compatible » ni « prouvé formellement » pour une garantie sans test public.

Source : Jepsen, 2026, discuté sur Hacker News le 31 octobre. Source en anglais.