Jepsen expone fallos críticos de seguridad y estabilidad en ParticleDB 1.1.4

La firma independiente de pruebas Jepsen ha publicado un informe exhaustivo sobre la versión 1.1.4 de ParticleDB, descubriendo violaciones significativas de seguridad y problemas de estabilidad en el motor de base de datos. El análisis, realizado entre las versiones 1.1.4 y 1.1.18.11.rc-22, destaca discrepancias entre las afirmaciones de marketing sobre verificación formal y el comportamiento real del sistema bajo carga. Para los ingenieros que evalúan infraestructuras para agentes de IA o aplicaciones de alto rendimiento, estos hallazgos plantean serias dudas sobre la preparación de la plataforma para su uso en producción.

Qué ocurrió

ParticleDB, desarrollado por Orkes para respaldar su plataforma de orquestación de flujos de trabajo Conductor, busca unificar SQL transaccional, almacenamiento clave-valor, búsqueda vectorial y analítica en un único motor basado en Rust. La empresa comercializa la base de datos como una solución con cumplimiento ACID completo y un rendimiento órdenes de magnitud superior a PostgreSQL, enfocándose en cargas de trabajo de agentes de IA. Para validar estas afirmaciones antes de un lanzamiento más amplio, Orkes contrató a Jepsen para probar la base de código refactorizada, comenzando con la versión 1.1.4. Las pruebas se centraron en el comportamiento de nodo único, ya que las compilaciones proporcionadas no admitían las funciones de clúster replicado disponibles únicamente en despliegues empresariales en la nube.

El equipo de Jepsen identificó 96 problemas distintos en varias categorías, incluyendo disponibilidad, funciones rotas, concurrencia de transacciones y corrupción de estado. Si bien algunos problemas se resolvieron en candidatos de lanzamiento posteriores, el informe detalla anomalías graves como fallos espontáneos sin mensajes de error, bloqueos (deadlocks) tras solo dos transacciones concurrentes e ignorancia silenciosa de los niveles de aislamiento de transacciones. El proceso de pruebas implicó simular fallos de procesos, corrupción de disco y fallas de red para estresar las garantías de durabilidad y consistencia del sistema.

Un punto importante de controversia fue la documentación relacionada con el aislamiento de transacciones y la durabilidad. La página principal de ParticleDB afirmaba "ACID Completo" y seguridad "formalmente probada" mediante TLA+, pero no se proporcionó ninguna especificación TLA+ durante la colaboración. Además, la documentación para modos de transacción como occ (Control de Concurrencia Optimista) y groupsync (sincronización WAL) contenía información contradictoria sobre si ofrecían durabilidad fuerte o aislamiento serializable. En muchos casos, la base de datos ignoraba silenciosamente los comandos SQL estándar para establecer niveles de aislamiento, recurriendo en su lugar a banderas de inicio mal explicadas en la documentación pública.

Cómo funciona

Jepsen prueba sistemas distribuidos inyectando fallos y observando si el sistema mantiene sus modelos de consistencia declarados. Para ParticleDB, el equipo utilizó una combinación de cargas de trabajo SQL existentes y nuevas pruebas diseñadas específicamente para las características únicas de la base de datos. Emplearon el verificador Elle para analizar grafos de dependencia de transacciones en busca de ciclos, lo cual indica violaciones de serializabilidad o aislamiento de instantánea (snapshot isolation). Las pruebas se ejecutaron tanto contra el cliente JDBC oficial de Postgres como contra el SDK nativo de Java de ParticleDB, aunque este último inicialmente no estaba disponible como dependencia Maven.

La suite de pruebas incluía cargas de trabajo que realizaban lecturas y escrituras aleatorias, adiciones a estructuras de listas y comprobaciones internas de consistencia dentro de transacciones individuales. Un método notable fue la carga de trabajo compare, que generaba sentencias SQL aleatorias y las ejecutaba tanto en ParticleDB como en PostgreSQL. Si los resultados divergían, la herramienta minimizaba el caso de prueba para reproducir el error. Este enfoque reveló que ParticleDB a menudo fallaba al igualar el comportamiento de PostgreSQL en consultas básicas, indicando una implementación incompleta o defectuosa del protocolo de comunicación (wire protocol) de Postgres.

La inyección de fallos desempeñó un papel clave en exponer problemas de durabilidad. Al usar LazyFS para simular la pérdida de escrituras no sincronizadas (fsync) y matar procesos abruptamente, Jepsen verificó si el Registro de Escritura Anticipada (WAL) preservaba correctamente los datos. Las pruebas cubrieron tres modos de sincronización WAL: sync, groupsync y nosync. Las discrepancias entre el comportamiento documentado de estos modos y su rendimiento real llevaron a varios hallazgos donde los datos podían perderse o corromperse incluso cuando los usuarios creían haber elegido configuraciones seguras.

Detalles clave

• Jepsen encontró 96 problemas en ParticleDB, que van desde cuellos de botella de rendimiento hasta violaciones críticas de la seguridad de los datos.
• La documentación afirmaba una seguridad "formalmente probada" mediante TLA+, pero no se proporcionó ninguna especificación para verificar esta afirmación.
• Los niveles de aislamiento de transacciones establecidos vía SQL eran frecuentemente ignorados en silencio, siendo el comportamiento gobernado por banderas de inicio opacas.
• Se produjeron bloqueos (deadlocks) severos en versiones hasta la 1.1.18.11.rc-6, congelando a veces el nodo tras solo dos transacciones concurrentes.
• El soporte para funciones estándar de Postgres era incompleto, con fallos en sentencias preparadas, agregados en expresiones CASE y operadores de exponente.
• Se observaron fallos espontáneos sin registros de errores en la versión 1.1.18.6, haciendo el sistema poco fiable para tareas de larga duración.

Por qué importa

Para ingenieros de software y líderes técnicos, este informe sirve como una advertencia sobre confiar en afirmaciones de marketing para infraestructuras críticas. ParticleDB se posiciona como una solución unificada para agentes de IA, un dominio donde la consistencia de datos es primordial. El descubrimiento de que los niveles de aislamiento de transacciones pueden ser ignorados silenciosamente significa que las aplicaciones que asumen una consistencia fuerte pueden sufrir condiciones de carrera sutiles y difíciles de depurar. Cuando una base de datos afirma "ACID Completo" pero se comporta con aislamiento de instantánea o garantías más débiles, los desarrolladores pueden diseñar sistemas que fallen bajo carga concurrente.

Los problemas de inestabilidad, incluidos los bloqueos y los fallos inexplicables, impactan directamente en la disponibilidad del sistema. En un entorno de producción, una base de datos que se congela después de unos segundos de actividad concurrente o falla sin registrar errores es operativamente insostenible. Estos defectos obligan a los equipos a invertir fuertemente en estrategias de monitoreo y soluciones alternativas, anulando los beneficios de rendimiento prometidos. Además, la implementación incompleta del protocolo de comunicación de Postgres significa que migrar aplicaciones existentes a ParticleDB no es un reemplazo directo (drop-in), requiriendo una refactorización y pruebas significativas.

La discrepancia entre la documentación pública y las guías internas de operadores también destaca una brecha de madurez. Cuando propiedades esenciales de seguridad se describen de manera diferente en textos de ayuda, páginas principales y documentos internos, los usuarios no pueden tomar decisiones informadas sobre el riesgo. Para organizaciones que consideran ParticleDB para flujos de trabajo de IA, la falta de pruebas de seguridad transparentes y verificables, junto con la presencia de bugs conocidos de corrupción de datos, sugiere que la tecnología aún no está lista para despliegues críticos.

Qué puedes hacer

• Evita usar versiones de ParticleDB anteriores a la 1.1.18.11.rc-7 en producción debido a problemas conocidos de bloqueo y fallo.
• Verifica empíricamente el comportamiento del aislamiento de transacciones en lugar de confiar en la documentación; prueba condiciones de carrera bajo carga concurrente.
• No asumas compatibilidad total con Postgres; audita tus consultas SQL en busca de funciones no soportadas como agregados en sentencias CASE o exponentes.
• Si usas ParticleDB, prefiere los modos table-2pl o serializable para datos críticos, a pesar de los posibles costos de rendimiento, para asegurar una consistencia más fuerte.
• Monitorea la corrupción silenciosa de datos implementando sumas de verificación (checksums) a nivel de aplicación o pruebas de comparación contra una base de datos confiable como PostgreSQL.
• Solicita acceso a guías internas de operadores o especificaciones detalladas de seguridad al proveedor antes de comprometerte con la plataforma.