⏱️ Lectura: 10 min
ParticleDB prometía ser «Full ACID» con 159.000 transacciones por segundo en la portada de su sitio. Jepsen, la consultora que Kyle Kingsbury dedica a destrozar bases de datos distribuidas con pruebas de caos, encontró 96 fallos de corrección entre las versiones 1.1.4 y 1.1.18.11.rc-22 de la base de datos ParticleDB. La mayoría de esos fallos aparecía con un solo servidor, un solo cliente y cero fallas de red.
📑 En este artículo
El reporte, publicado el 31 de octubre de 2026 y financiado por Orkes, la empresa detrás del motor, es el típico análisis Jepsen: mezcla hallazgos cómicos (filas parcialmente invisibles que no se podían borrar, tablas eliminadas que reaparecían distorsionadas) con otros serios, como pérdida de escrituras confirmadas incluso en el modo de aislamiento serializable, el más estricto que ofrece el motor.
TL;DR
- Jepsen halló 96 fallos en la base de datos ParticleDB, de Orkes, entre las versiones 1.1.4 y 1.1.18.11.rc-22
- El modo serializable, el más estricto de ParticleDB, permitió anomalías internas y Lost Update
- La configuración groupsync perdía escrituras confirmadas pese a anunciar la misma durabilidad que sync
- Orkes lanzó la versión 1.1.19-rc.13 y afirma haber resuelto todos los fallos restantes
- Su propia portada prometía «Full ACID» aunque el texto debajo describía snapshot isolation
Qué es la base de datos ParticleDB
La base de datos ParticleDB es un motor multimodal que Orkes construyó para cargas de inteligencia artificial: combina SQL transaccional, almacenamiento clave-valor, búsqueda vectorial y analítica en vivo mediante funciones definidas por el usuario llamadas Particles. Escrita en Rust, expone protocolos Postgres, Redis, gRPC y HTTP2 para integrarse con sistemas existentes.
El objetivo declarado es reemplazar el típico mosaico de cachés, colas y almacenes separados que usan las aplicaciones de IA actuales. Orkes afirma que ParticleDB es órdenes de magnitud más rápido que Postgres mientras conserva las mismas garantías de seguridad transaccional.
Qué pasó
Orkes contrató a Jepsen para auditar las versiones refactorizadas de ParticleDB antes de un lanzamiento más amplio. El resultado fueron 96 problemas, desde los pedestres (caídas del servidor, deadlocks, pérdida de datos) hasta los más curiosos: filas parcialmente invisibles que no se podían eliminar, consultas WHERE 4 = 5 que igual devolvían filas, tablas borradas que reaparecían con forma distinta, columnas confundidas entre sí y strings que se convertían en enteros.
La mayoría de esos 96 casos no necesitó un clúster bajo estrés: bastó un solo servidor, un solo cliente y ninguna falla de red para reproducirlos. Para la versión 1.1.18.11.rc-22, Orkes había resuelto todos los problemas menos diez. Pero entre esos diez quedaban los más graves: ParticleDB seguía perdiendo escrituras confirmadas durante operación normal con occ, su modo de transacciones por defecto, y permitía anomalías internas y Lost Update incluso con serializable, el ajuste más fuerte disponible.
Orkes ya respondió. Según el propio reporte de Jepsen, la empresa lanzó la versión 1.1.19-rc.13 y asegura que ahí quedan resueltos todos los problemas que seguían abiertos.
Contexto e historia
Orkes no construyó ParticleDB como un producto aislado. La empresa opera Conductor, una plataforma de orquestación de flujos de trabajo que originalmente guardaba su estado en Redis y Postgres. Para mejorar el rendimiento, Orkes decidió escribir su propia base de datos en lugar de seguir combinando dos motores distintos.
La versión 1.0.0 de ParticleDB tenía un set de funciones limitado, pensado específicamente para las consultas de Conductor, y se desplegó como backend de algunos clústeres de producción. Varios clientes de Orkes siguieron el mismo camino. Antes de un lanzamiento más amplio al público, Orkes hizo un refactor mayor: agregó un protocolo de cable propio, más tipos de datos y consultas OLAP adicionales, y lanzó esas versiones de forma silenciosa en particledb.ai. Jepsen empezó a probar justamente esas versiones refactorizadas, a partir de la 1.1.4.
Un detalle que el reporte deja claro: ParticleDB también ofrece un clúster replicado usando el protocolo de consenso Raft, pero esa función solo está disponible en despliegues de nube empresarial. Las builds que Orkes entregó a Jepsen no soportaban replicación, así que todo lo analizado corresponde únicamente a comportamiento de un solo nodo.
El mecanismo detrás de los fallos
La página de inicio de ParticleDB aseguraba estar «formalmente probada» con una especificación en TLA+. Durante la colaboración con Jepsen, sin embargo, no existía ninguna especificación TLA+ disponible, así que no queda claro qué propiedades se habrían demostrado ni si describían al ParticleDB real.
La mayoría de los motores SQL controlan el nivel de aislamiento de una transacción con la instrucción SET TRANSACTION ISOLATION LEVEL. ParticleDB la ignora o la rechaza. A veces le dice al usuario que use READ COMMITTED, un nivel relativamente débil; otras veces acepta el pedido de otro nivel y lo ignora en silencio, sin avisar.
En cambio, el aislamiento real depende de un flag de arranque, --txn-mode, con cuatro modos documentados:
| Modo | Comportamiento | Cuándo usarlo |
|---|---|---|
| fast | Sin locks; commit al escribir | Cargas masivas, benchmarks de un solo escritor |
| occ (default) | Overlay más validación OCC al hacer commit | OLTP general, pensado para ser seguro bajo concurrencia |
| zero-copy-occ | OCC anclado a partición; transacciones de una sola partición evitan coordinación cruzada | OLTP de alto rendimiento sobre cargas afines a partición |
| table-2pl | Locks exclusivos de tabla al primer toque | Serialización más estricta, semántica simple |
El problema es que la documentación nunca explicó qué garantizaba cada modo en términos formales. ¿fast equivalía a Read Atomic, a Read Uncommitted o a otra cosa? Jepsen tampoco pudo confirmarlo del todo con occ, el modo que usa cualquier instalación nueva por defecto.
La confusión se repite con la durabilidad del Write-Ahead Log. ParticleDB ofrece tres tácticas: sync hace fsync en cada commit, groupsync agrupa varias transacciones en un solo fsync, y nosync no hace fsync en absoluto. La documentación del motor de transacciones dice que sync ofrece «mayor durabilidad» que groupsync.
$ particledb start --help
--txn-mode groupsync # "COMMIT waits for flush"Pero la ayuda de línea de comandos asegura que groupsync garantiza que «COMMIT espera al flush», y la guía interna de operación de Orkes coincide: según ese documento, groupsync ofrece «la misma durabilidad que sync«. Tres fuentes oficiales, tres versiones distintas de la misma garantía.
⚠️ Ojo: la portada de ParticleDB decía literalmente «Full ACID. 159K TPS.» y, justo debajo, el texto describía «snapshot isolation», un nivel de aislamiento que por definición no es completamente serializable.
Impacto y análisis
Para equipos que evalúan la base de datos ParticleDB en producción, el reporte es una señal de alerta clara. No es que ParticleDB no sirva: la mayoría de los 96 fallos ya estaban resueltos para la última versión probada. El problema es que los que quedaban afectaban justo el modo por defecto (occ) y el modo que, en teoría, ofrece más garantías (serializable).
Jepsen aclara que financió el estudio la propia Orkes, siguiendo la política de ética de Jepsen, que exige publicar los resultados sin filtrar hallazgos negativos. Eso le da credibilidad al informe, aunque también explica por qué Orkes respondió tan rápido con una nueva versión.
La limitación más importante del estudio es que solo cubre comportamiento de un solo nodo. ParticleDB vende replicación vía Raft para sus clientes de nube empresarial, pero esa parte del sistema nunca se probó porque las builds entregadas a Jepsen no la soportaban. Cualquier equipo que piense correr un clúster replicado en producción debería pedir una auditoría separada antes de confiar en esa capa.
Qué sigue
Orkes ya lanzó la versión 1.1.19-rc.13 y sostiene que resuelve todos los fallos que seguían abiertos al cierre del reporte. Jepsen no confirma de forma independiente esa afirmación en el documento publicado, así que por ahora es la palabra de Orkes contra sus propios resultados anteriores.
Para cualquier equipo que ya use o esté evaluando ParticleDB, el paso práctico es elegir --txn-mode con el mismo cuidado que recomienda la propia documentación del proyecto: la mejor práctica publicada advierte que el modo «cambia la corrección y el rendimiento más que el texto SQL», así que no conviene dejarlo en el valor por defecto sin entender qué cubre.
📖 Resumen en Telegram: Ver resumen
Probalo vos: antes de poner la base de datos ParticleDB en producción, corré tu propio set de pruebas de concurrencia con el --txn-mode que pensás usar y compará el resultado contra el reporte de Jepsen en jepsen.io.
Preguntas frecuentes
¿ParticleDB cumple de verdad con ACID?
No de forma completa en las versiones auditadas. Jepsen encontró pérdida de escrituras confirmadas en el modo por defecto y anomalías incluso en serializable, el nivel más estricto que ofrece ParticleDB.
¿Qué modo de transacción de ParticleDB es más seguro?
Según la documentación, table-2pl ofrece la serialización más estricta con locks exclusivos de tabla, aunque el reporte de Jepsen no confirma que ningún modo esté completamente libre de fallos en todas las versiones probadas.
¿ParticleDB soporta replicación?
Sí, mediante el protocolo Raft, pero solo en despliegues de nube empresarial. Jepsen no evaluó esa capa porque las builds que usó no la incluían.
¿Qué es Orkes y por qué construyó ParticleDB?
Orkes es la empresa detrás de Conductor, una plataforma de orquestación de flujos de trabajo. Construyó ParticleDB para reemplazar la combinación de Redis y Postgres que usaba Conductor y mejorar el rendimiento.
¿Ya se resolvieron los fallos que halló Jepsen en ParticleDB?
Orkes dice que la versión 1.1.19-rc.13 resuelve todos los problemas que seguían abiertos al cierre del reporte, aunque Jepsen no lo confirma de forma independiente en el documento publicado.
Referencias
- Jepsen: ParticleDB 1.1.4: el reporte original de Kyle Kingsbury con los 96 fallos encontrados.
- Jepsen en GitHub: el framework y la metodología que usa Jepsen para auditar bases de datos distribuidas.
- Raft Consensus Algorithm: el protocolo de replicación que ParticleDB ofrece en su nube empresarial.
- Conductor OSS: la plataforma de orquestación de Orkes que originó el desarrollo de ParticleDB.
- ACID (Wikipedia): definición de las propiedades de atomicidad, consistencia, aislamiento y durabilidad.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Imagen destacada: Foto de Markus Stickling en Unsplash
¿Te sirvió? ¿Te dio otro error? Contalo abajo: las preguntas se responden y le sirven al siguiente que llegue.
Dejar un comentario
0 Comentarios