Contexte et objectifs du test

ParticleDB, développé en Rust par Orkes, se présente comme une base de données unifiée capable de gérer SQL transactionnel, KV, recherche vectorielle et fonctions utilisateur. La version 1.1.4 a été soumise à l’évaluation Jepsen afin de vérifier les promesses de « Full ACID » et de 159 K TPS annoncées sur le site officiel. Les tests se sont limités à un nœud unique, car les builds fournis ne supportaient pas la réplication Raft réservée aux déploiements cloud d’entreprise.

Architecture et modes de transaction

Le moteur repose sur un Write‑Ahead Log (WAL) configurable en trois modes : fsync (flush à chaque commit), groupsync (regroupement de plusieurs commits avant flush) et nosync (aucune synchronisation). La documentation affirme que groupsync « COMMIT waits for flush », alors que le texte marketing le décrit comme moins durable que sync, créant une ambiguïté sur la persistance des données.

Le paramètre --txn-mode détermine le modèle d’isolation. Les modes répertoriés sont :

fast
occ
zero-copy-occ
table-2pl
occ-v3

Les descriptions officielles sont incomplètes : fast est indiqué comme « weaker isolation », occ comme « safe under concurrency », tandis que table-2pl prétend offrir la « strictest serialization ». Aucun niveau d’isolation standard (READ COMMITTED, SERIALIZABLE) n’est explicitement garanti, et les requêtes SET TRANSACTION ISOLATION LEVEL sont rejetées ou ignorées.

Analyse des garanties de sécurité

Jepsen a confronté les déclarations marketing à la réalité observée. Le test a simulé des crashs de processus, des pertes de WAL non synchronisés via LazyFS et des corruptions de disque. Sous le mode groupsync avec occ‑v3, des anomalies d’isolation ont été détectées : des transactions lisant des valeurs précédemment écrites ont parfois observé des états intermédiaires, violant la propriété de snapshot isolation annoncée. Le mode fast, pourtant présenté comme performant, a produit des violations de sérialisation dans les workloads à forte contention.

Le rapport souligne l’absence de spécification TLA+ malgré la promesse d’une preuve formelle. Sans modèle formel, il est impossible de vérifier que les invariants d’atomicité et de durabilité sont respectés dans tous les scénarios de panne.

Limitations et perspectives

Les incohérences entre la documentation, les messages d’aide CLI et le comportement observé compliquent la configuration sûre du système. Le manque de support de réplication empêche d’évaluer la cohérence distribuée, un aspect critique pour les déploiements en production. Enfin, la non‑disponibilité du SDK Java officiel et la dépendance à un client PostgreSQL JDBC (v42.7.11) limitent l’écosystème d’applications compatibles.

En l’état, ParticleDB 1.1.4 ne satisfait pas les exigences de sécurité attendues d’une base de données prétendant être ACID. Les développeurs doivent choisir des modes conservateurs (groupsync + occ‑v3) et surveiller étroitement les journaux de crash pour éviter des corruptions silencieuses. Une révision de la documentation et la publication d’une spécification formelle apparaissent comme des prérequis pour regagner la confiance des utilisateurs.