Jepsen halla 96 fallos de corrección en ParticleDB
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.
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.
Jepsen reprodujo la mayoría de los 96 fallos con un solo servidor, un solo cliente y cero fallas de red.
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:
ModoComportamientoCuándo usarlofastSin locks; commit al escribirCargas masivas, benchmarks de un solo escritorocc (default)Overlay más validación OCC al hacer commitOLTP general, pensado para ser seguro bajo concurrenciazero-copy-occOCC anclado a partición; transacciones de una sola partición evitan coordinación cruzadaOLTP de alto rendimiento sobre cargas afines a particióntable-2plLocks exclusivos de tabla al primer toqueSerializació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.
El modo serializable, el más estricto que ofrece ParticleDB, también mostró Lost Update según Jepsen.
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.
Conductor: Durable Execution for Workflows and Agents (32.3k stars)
What it does
All text below is quoted directly from the project README.
>Build agents that adapt. Run graphs that endure.
>Conductor is an open-source durable execution platform for microservices, AI agents, and adaptive workflow graphs. It turns runtime choices (loops, branching, fan-out, tool calls, approvals, retries, and cancellation) into durable, inspectable execution. It originated at Netflix and is actively maintained by Orkes and the community.
Why Conductor is the workflow engine of choice for developers:
- Durable execution: Every step is persisted. Survives crashes, restarts, and network failures with configurable retries and timeouts.
- Explicit orchestration: Keep orchestration as a versioned, inspectable graph while workers and built-in tasks perform business logic and side effects.
- AI agent orchestration: Native LLM tasks, MCP tool calling, human approval, and vector workflows for RAG.
- Durable adaptive graphs: Govern runtime-selected paths, bounded fan-out, tool calls, approvals, retries, cancellation, and recovery.
- Dynamic at runtime: Dynamic forks, tasks, and sub-workflows can be resolved at runtime. Validate generated workflow definitions before starting them.
- Execution recovery: Inspect an execution, then restart, rerun, retry, pause, resume, or terminate it according to the workflow's policy.
- Operate at your scale: Scale servers and workers independently, then use task domains, rate limits, concurrency limits, and metrics for control.
- Polyglot workers: Workers in Java, Python, Go, JavaScript, C#, Ruby, or Rust. Workers poll, execute, and report, run them anywhere.
- Self-hosted, no lock-in: Apache 2.0. 5 persistence backends, 6 message brokers. Runs anywhere Docker or a JVM runs.
>Conductor workers are plain code, any language, any library, any I/O. The orchestration layer is declarative and machine-readable, so developers can keep their preferred SDK or framework while operators retain durable state, policy boundaries, replay, versioning, and auditability.
>Every step is durably persisted, no framework, no SDK lock-in. Code-first engines force your code to be deterministic so the framework can replay it. Conductor makes the engine deterministic, so your code doesn't have to be.
>Conductor Skills let AI coding assistants (Claude Code, Gemini CLI, and others) create, manage, and deploy Conductor workflows directly from your terminal.
Repository
conductor-oss/conductor
Repository stats
|Metric|Value|
|:-|:-|
|Stars|32,304|
|Forks|1,033|
|Last release|v3.32.5 (2026-09-25)|
|Languages|Java 59.5%, TypeScript 23.8%, JavaScript 11.3%|
|Contributors|124|
|AI contributor accounts (Claude / Codex / Cursor / Copilot)|claude (93 commits)|
|AI co-authored commits|Claude: 99|
Main contributor
|Field|Value|
|:-|:-|
|Name|Viren Baraiya|
|GitHub|@v1r3n|
|Commits to this repo|328 (top contributor)|
|Bio|Founder - orkes.io|
|Company|@orkes-io|
|Followers|139|
|Public repos|31|
|On GitHub since|2012-08-30|
----------------------------------------------------------------------------------------
Discover the best GitHub repos without the endless scrolling.
Get top repos organized by category (AI, DevOps, Databases & more), plus key takeaways from developers' most useful comments - all in one free, twice-weekly newsletter.
👉 Get the best repos & community insights - Free
22 points · 1 comment
Mentions
Jepsen halla 96 fallos de corrección en ParticleDB 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. 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. Jepsen reprodujo la mayoría de los 96 fallos con un solo servidor, un solo cliente y cero fallas de red. 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: ModoComportamientoCuándo usarlofastSin locks; commit al escribirCargas masivas, benchmarks de un solo escritorocc (default)Overlay más validación OCC al hacer commitOLTP general, pensado para ser seguro bajo concurrenciazero-copy-occOCC anclado a partición; transacciones de una sola partición evitan coordinación cruzadaOLTP de alto rendimiento sobre cargas afines a particióntable-2plLocks exclusivos de tabla al primer toqueSerializació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. El modo serializable, el más estricto que ofrece ParticleDB, también mostró Lost Update según Jepsen. 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.
Conductor: Durable Execution for Workflows and Agents (32.3k stars) What it does All text below is quoted directly from the project README. >Build agents that adapt. Run graphs that endure. >Conductor is an open-source durable execution platform for microservices, AI agents, and adaptive workflow graphs. It turns runtime choices (loops, branching, fan-out, tool calls, approvals, retries, and cancellation) into durable, inspectable execution. It originated at Netflix and is actively maintained by Orkes and the community. Why Conductor is the workflow engine of choice for developers: - Durable execution: Every step is persisted. Survives crashes, restarts, and network failures with configurable retries and timeouts. - Explicit orchestration: Keep orchestration as a versioned, inspectable graph while workers and built-in tasks perform business logic and side effects. - AI agent orchestration: Native LLM tasks, MCP tool calling, human approval, and vector workflows for RAG. - Durable adaptive graphs: Govern runtime-selected paths, bounded fan-out, tool calls, approvals, retries, cancellation, and recovery. - Dynamic at runtime: Dynamic forks, tasks, and sub-workflows can be resolved at runtime. Validate generated workflow definitions before starting them. - Execution recovery: Inspect an execution, then restart, rerun, retry, pause, resume, or terminate it according to the workflow's policy. - Operate at your scale: Scale servers and workers independently, then use task domains, rate limits, concurrency limits, and metrics for control. - Polyglot workers: Workers in Java, Python, Go, JavaScript, C#, Ruby, or Rust. Workers poll, execute, and report, run them anywhere. - Self-hosted, no lock-in: Apache 2.0. 5 persistence backends, 6 message brokers. Runs anywhere Docker or a JVM runs. >Conductor workers are plain code, any language, any library, any I/O. The orchestration layer is declarative and machine-readable, so developers can keep their preferred SDK or framework while operators retain durable state, policy boundaries, replay, versioning, and auditability. >Every step is durably persisted, no framework, no SDK lock-in. Code-first engines force your code to be deterministic so the framework can replay it. Conductor makes the engine deterministic, so your code doesn't have to be. >Conductor Skills let AI coding assistants (Claude Code, Gemini CLI, and others) create, manage, and deploy Conductor workflows directly from your terminal. Repository conductor-oss/conductor Repository stats |Metric|Value| |:-|:-| |Stars|32,304| |Forks|1,033| |Last release|v3.32.5 (2026-09-25)| |Languages|Java 59.5%, TypeScript 23.8%, JavaScript 11.3%| |Contributors|124| |AI contributor accounts (Claude / Codex / Cursor / Copilot)|claude (93 commits)| |AI co-authored commits|Claude: 99| Main contributor |Field|Value| |:-|:-| |Name|Viren Baraiya| |GitHub|@v1r3n| |Commits to this repo|328 (top contributor)| |Bio|Founder - orkes.io| |Company|@orkes-io| |Followers|139| |Public repos|31| |On GitHub since|2012-08-30| ---------------------------------------------------------------------------------------- Discover the best GitHub repos without the endless scrolling. Get top repos organized by category (AI, DevOps, Databases & more), plus key takeaways from developers' most useful comments - all in one free, twice-weekly newsletter. 👉 Get the best repos & community insights - Free
We started Conductor at Netflix. To everyone who has contributed a fix, improved the docs, or helped another developer get unstuck - thank you. 🙏 What was your first contribution to Conductor? conductor-oss/conductor Geographic distribution of contributors. t.co