Jepsen: ParticleDB 1.1.4

Artículo original ↗ Discusión en Hacker News ↗

Un nuevo análisis de Jepsen sobre ParticleDB, una base de datos compatible con Postgres y comercializada como “formalmente probada” y centrada en IA, informa una cantidad inusualmente grande de errores graves de corrección, desde escrituras perdidas hasta resultados de consulta sin sentido como `WHERE 4 = 5` devolviendo filas. Los comentaristas sostienen que la magnitud y la naturaleza de los fallos apuntan a errores fundamentales de diseño y de QA, probablemente exacerbados por una fuerte dependencia de modelos de lenguaje a gran escala, y ven el episodio como una advertencia sobre los proyectos de bases de datos impulsados por el hype. Muchos concluyen que un sistema así no es seguro para uso en producción y que las pruebas al estilo Jepsen deberían ser un requisito básico para cualquier almacén de datos serio.

Alcance y gravedad de los problemas

  • Los comentaristas describen el informe de Jepsen como inusualmente condenatorio en comparación con los análisis típicos de bases de datos.
  • Se dice que ParticleDB presenta numerosos errores graves: caídas, interbloqueos, pérdida de datos, comportamiento SQL absurdo (por ejemplo, predicados imposibles que devuelven filas, predicados sobre columnas inexistentes) y anomalías transaccionales generalizadas incluso en un solo nodo sin fallos.
  • Varios participantes sostienen que esto sugiere un diseño fundamentalmente defectuoso (“incorrecto por construcción”), no solo errores локализados.

Reclamaciones de marketing vs. realidad

  • Fuerte crítica al marketing: afirmaciones de estar “formalmente probado” con TLA+, ser “compatible con PostgreSQL”, compilaciones listas para producción y reclamaciones extremas de rendimiento (por ejemplo, más rápido que Redis, órdenes de magnitud más rápido que Postgres).
  • El informe de Jepsen señala que no había disponible ninguna especificación TLA+, y que la compatibilidad básica con Postgres claramente falló.
  • Algunos señalan que el sitio web y la redacción parecen haber sido revisados silenciosamente después de los resultados de las pruebas.

Proceso de pruebas y control de calidad

  • Muchos no entienden cómo se publicaron errores tan básicos: infieren que faltaban pruebas, que las pruebas eran ineficaces o que no se ejecutaban.
  • Jepsen señala que, supuestamente, el arnés de Jepsen para Postgres existente se había ejecutado antes, pero falla de inmediato en la versión probada.
  • Los comentaristas ven esto como evidencia de problemas estructurales profundos de QA, posiblemente incluyendo una dependencia excesiva de agentes automatizados.

Papel de la IA / “vibecoding”

  • Se especula repetidamente que se usaron modelos de lenguaje a gran escala de forma intensiva para escribir tanto la base de datos como sus pruebas, sin que los humanos entendieran por completo el sistema.
  • “Base de datos vibecodificada” se convierte en una abreviatura para código y documentación generados por IA y mal validados.
  • Algunos señalan que la IA puede ser poderosa en manos capaces, pero aquí parece haber amplificado la inexperiencia y el mal juicio.

Respuesta del proveedor y confianza futura

  • Un miembro del equipo afirma que desde entonces los problemas se han abordado, que el motor se rediseñó, que ahora se ejecutan cargas de trabajo de Jepsen a diario y que las pruebas se han reforzado.
  • La mayoría de las respuestas son muy escépticas: arreglar los fallos listados se califica como “lo mínimo indispensable”, y la gente cuestiona por qué un sistema tan inmaduro se comercializó como listo para producción y formalmente verificado.
  • Varios dicen que nunca desplegarían el producto; algunos sugieren empezar de cero o abandonar por completo el sector, citando daños reputacionales.
  • Una minoría enfatiza que el propósito de Jepsen es encontrar errores para que puedan corregirse y que sobrevivir a futuras ejecuciones de Jepsen podría restaurar algo de confianza.

Conclusiones más amplias

  • Muchos sostienen que todo proveedor de bases de datos debería someterse a pruebas al estilo Jepsen, y que los informes francos, incluso duros, son necesarios para proteger a los usuarios.
  • El hilo destaca un contraste entre la ingeniería de bases de datos rigurosa, impulsada por pruebas, y el desarrollo impulsado por el hype y acelerado por IA que descuida la corrección.