El incidente de ParticleDB revela una falla sistémica en la calidad y el proceso de desarrollo de una base de datos distribuida, exacerbada por la confianza en herramientas de generación de código (LLMs) sin una validación rigurosa. La causa raíz principal es una combinación de un control de calidad deficiente y una documentación engañosa sobre las garantías de consistencia y durabilidad. A pesar de las afirmaciones de "Full ACID" y "formalmente probado", ParticleDB exhibió una "biblioteca de confusión" con 96 problemas, la mayoría en instancias de un solo nodo sin inyección de fallas. Esto incluye deadlocks, crashes, corrupción de datos, violaciones de restricciones, comportamiento errático de predicados y un amplio espectro de anomalías transaccionales (pérdida de escrituras, G1a, G1b, P4, G-Single, A5A, Stale Read).
La cascada de fallos se originó en una base de código fundamentalmente inestable, donde incluso operaciones SQL básicas como INSERT, UPDATE y DELETE funcionaban de manera impredecible. La falta de un conjunto de pruebas unitarias y de integración robusto permitió que errores triviales, como la incapacidad de hacer cumplir las restricciones NOT NULL o UNIQUE, persistieran a través de múltiples versiones. La documentación, en lugar de ser una salvaguarda, se convirtió en un vector de desinformación, prometiendo características y garantías que el sistema no ofrecía. Esto creó una falsa sensación de seguridad para los desarrolladores y usuarios, que esperaban un comportamiento compatible con PostgreSQL y garantías ACID.
Las salvaguardas fallaron en múltiples niveles. El proceso de QA de Orkes, que supuestamente incluía el uso de Jepsen y SQLancer, no detectó los problemas más básicos. Esto sugiere que las pruebas no se ejecutaron correctamente, o que los resultados no se analizaron adecuadamente. La promesa de una "prueba formal de TLA+" no se materializó en un sistema correcto. La dependencia de LLMs para generar código y documentación, sin una verificación humana experta, parece haber contribuido a la proliferación de errores y a la dificultad para comprender y depurar el sistema. La falta de changelogs detallados y la aparición de "nuevas builds" sin explicaciones técnicas profundas impidieron una comprensión clara de las causas y soluciones de los problemas, lo que es crítico en el desarrollo de sistemas de bases de datos.