ParticleDB es una base de datos multimodelo desarrollada por Orkes para dar soporte a su plataforma de orquestación de flujos de trabajo, Conductor. Construido en Rust, el sistema tiene como objetivo unificar diversas cargas de trabajo —incluyendo SQL transaccional, almacenamiento de clave-valor, búsqueda vectorial y analítica en vivo— en un solo motor. Aunque los desarrolladores afirmaron que la base de datos estaba "formalmente probada" y ofrecía cumplimiento "Full ACID", un análisis de Jepsen de las versiones 1.1.4 hasta la 1.1.18.11.rc-22 reveló discrepancias significativas entre estas afirmaciones y el comportamiento real del sistema.
El análisis identificó 96 problemas distintos, muchos de los cuales ocurrieron en instancias de un solo nodo saludables sin ningún fallo simulado. Estos problemas variaron desde problemas básicos de estabilidad, como fallos espontáneos y bloqueos, hasta anomalías lógicas más complejas. Por ejemplo, el informe documentó casos en los que las filas se volvían "parcialmente invisibles" y no podían eliminarse, casos en los que las consultas devolvían resultados para condiciones imposibles (por ejemplo, `WHERE 4 = 5`), y escenarios en los que las tablas eliminadas volvían a aparecer en formas distorsionadas. Además, la base de datos mostró fallos de seguridad de tipos, como cadenas que se convertían inesperadamente en números enteros y mapeos de columnas confusos.
El análisis de Jepsen identificó 96 problemas distintos, muchos de los cuales ocurrieron en instancias de un solo nodo saludables sin ningún fallo simulado.
Uno de los principales hallazgos técnicos involucró los modos de aislamiento de transacciones de la base de datos. Aunque ParticleDB comercializaba propiedades "Full ACID", el análisis encontró que el modo predeterminado `occ` (Optimistic Concurrency Control) continuaba perdiendo escrituras confirmadas durante la operación normal. Adicionalmente, el sistema permitía anomalías internas y errores de "Lost Update" incluso cuando estaba configurado en `serializable`, que es típicamente el ajuste de aislamiento más fuerte. Si bien Orkes ha lanzado desde entonces una versión más reciente (1.1.19-rc.13) que afirma resolver estos problemas, el informe de Jepsen destaca una brecha significativa entre las garantías de seguridad anunciadas por la base de datos y su rendimiento en pruebas rigurosas.
Más allá de la consistencia, el análisis también señaló graves cuellos de botella en el rendimiento en configuraciones específicas. En versiones anteriores, se descubrió que el modo de transacción `table-2pl` era esencialmente inutilizable, ya que la mayoría de las transacciones se bloqueaban durante 10, 20 o incluso 30 segundos antes de fallar. Aunque se realizaron algunas mejoras en versiones posteriores, el informe subraya que los mecanismos internos de la base de datos para manejar la concurrencia y la sincronización del registro de escritura anticipada (WAL) eran inconsistentes entre diferentes fuentes de documentación, lo que provocaba un comportamiento impredecible para los usuarios que intentaban lograr operaciones seguras de alto rendimiento.