El Ecosistema Startup

¿Qué cambió realmente en Apache Cassandra 6?

Apache Cassandra 6 introdujo Accord, un protocolo de consenso sin líderes que finalmente permite transacciones ACID multi-partición en la base de datos que usan empresas como Apple, eBay, Netflix y Bloomberg. Pero hay una advertencia crucial: esta versión sigue siendo alfa desde abril de 2026, sin fecha oficial de disponibilidad general confirmada.

Para founders que han mantenido workloads transaccionales en bases relacionales mientras migran todo lo demás a Cassandra, esto representa un punto de inflexión arquitectónico. El problema es que las garantías prometidas por Accord aún no tienen benchmarks públicos ni números de latencia medidos — solo afirmaciones protocolares sobre rondas de red.

La evolución de Cassandra es notable: desde un modelo eventualmente consistente sin transacciones en su primer release hasta un sistema SQL-like con isolación serializable estricta en múltiples particiones. Pero el camino entre la propuesta original (CEP-15, octubre de 2021) y el primer artefacto ejecutable (6.0-alpha1, marzo de 2026) tomó cuatro años y medio, cerrándose en el trunk en enero de 2025.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

¿Cómo funciona Accord y qué limita su adopción inmediata?

Accord resuelve el clásico tradeoff de sistemas distribuidos: prior acercamientos necesitaban un coordinador central (punto único de falla con penalización WAN), estaban limitados a alcance de una sola partición, o degradaban rendimiento bajo fallos. Accord combina electorados flexibles de fast-path con un buffer de reordenamiento de timestamps, sobre un modelo sin líderes, entregando:

Atomicidad cross-partición verdadera entre múltiples tablas y partition keys
Isolación serializable estricta, formalmente verificada
Latencia de una sola ronda WAN en condiciones normales
Rendimiento tolerante a fallos sin líderes elegidos

La sintaxis CQL usa bloques BEGIN TRANSACTION / COMMIT TRANSACTION familiares:

BEGIN TRANSACTION
  LET sender = (SELECT balance FROM accounts WHERE user_id = ?);
  IF sender.balance >= 100 THEN
    UPDATE accounts SET balance = balance - 100 WHERE user_id = ?;
    UPDATE accounts SET balance = balance + 100 WHERE user_id = ?;
  END IF
COMMIT TRANSACTION

Pero este no es un modelo interactivo como el RDBMS tradicional. Es un modelo one-shot: todo el bloque se envía como una declaración única. La razón técnica es que el conjunto completo de keys debe declararse antes de ejecución, y no puede cambiar durante ella. Esta declaración upfront es el precio pagado por el tracking de dependencias sin líderes.

Restricciones críticas documentadas

Las limitaciones son sustanciales y afectan decisiones de diseño reales:

Un LET SELECT debe retornar exactamente una fila, especificar toda la partition key con igualdad, y no puede usar condiciones de rango, múltiples particiones ni agregaciones
Dentro del bloque transactional: no se permiten counter tables, funciones agregadas, ORDER BY, GROUP BY, TTLs/timestamps custom, ni range DELETE
Condiciones IF soportan solo AND (sin OR), comparaciones null siempre son false
No existe arithmetic de row-reference en SET: algo como SET balance = sender.balance - 100 no es válido; el valor computado debe pasarse como parámetro
SELECTs que retornan resultados deben venir antes de cualquier statement modificador

Niveles de consistencia no soportados

Un detalle que afecta a cualquier operador multi-DC: Accord no soporta LOCALQUORUM, LOCALONE ni LOCALSERIAL. Si tu workload depende de latencia DC-local, actualmente no hay forma de expresar ese requisito. CEP-15 lista un reemplazo LOCALSERIAL solo como «meta futura». Especificar ONE como commit consistency level se ejecuta silenciosamente como QUORUM.

Modos de operación por tabla

Accord no se activa globalmente; se selecciona por tabla tras habilitar accord.enabled: true en cassandra.yaml:

off (default): comportamiento actual. SERIAL va por Paxos, todo lo demás usa eventual consistency
full (recomendado): todas las reads y writes van por Accord. Usa single-replica reads y async commit. WAN round trips bajan de 2 a 1
mixed_reads: writes por Accord, reads no-SERIAL por ruta existente. Requiere sync commit, totalizando 2 WAN round trips

La documentación recomienda ir directo de off a full.

¿Qué significa esto para tu startup?

Si estás evaluando si adoptar Cassandra 6 hoy, aquí está la realidad operativa basada en lo documentado:

Escenarios donde vale la pena probar Accord:

Workloads que acumularon código saga/batch para simular LWT multi-partición
Perfiles de latencia donde REGIONGLOBAL o GLOBALQUORUM son aceptables
Equipos que pueden medir patrones de conflicto contra el alpha antes de producción

Escenarios donde NO necesitas preocuparte aún:

Workloads multi-DC que dependen de LOCAL_QUORUM (no hay forma de expresarlo)
Workloads que usan counter tables (no son posibles con transactions)
Migraciones que esperan transacciones interactivas estilo RDBMS (es un modelo one-shot)
Decisiones basadas en benchmark numbers (no existen números oficiales aún)

Acciones concretas para founders

1. Identifica tus workloads candidatos:

Revisa tu stack actual. ¿Hay flujos que actualmente delegaste a PostgreSQL o MySQL exclusivamente por garantías transaccionales? Estos son los candidatos primarios para re-evaluación. Documenta cuántas líneas de código manejan retry logic, race condition guards y compensating operations hoy.

2. Evalúa en non-production antes de comprometerse:

Los quarterly alphas vienen sin soporte ni backports. Si decides probar Accord, hazlo en ambientes aislados primero. Mide tus propios patrones de conflicto contra el alpha. La documentación sugiere empezar con 5 LETs y menos de 3 particiones, aunque aclara explícitamente que esto es «una guía sugerida, no un límite derivado empíricamente».

3. Planifica la migración TCM con anticipación:

Antes de que Accord funcione, debes habilitar Transactional Cluster Metadata (TCM), que reemplaza Gossip como mecanismo primario de coordinación de metadata. La inicialización requiere acuerdo total del cluster; no se soportan clusters mixed-version. Deshabilita cualquier automatización que dispare schema changes o node bootstrapping durante la ventana de upgrade.

4. Considera CEP-37 (Automated Repair) primero:

Ya backported a Cassandra 5.0.8 (abril 2026), Automated Repair mueve full e incremental repair nativamente dentro de la base de datos. Si usas Reaper o scripts cron, puedes adoptar esta mejora sin esperar Cassandra 6 GA. Ejecuta ambos en paralelo durante un ciclo completo antes de decommissionar tooling externo.

Conclusión

Accord representa uno de los cambios generacionales más ambiciosos en la historia de Cassandra. Lograr isolación serializable estricta en sistemas geo-distribuidos sin comprometer fault tolerance tiene una respuesta probada y funcional. El código llegó en alpha1, pero eso es más cercano a «un tag de fecha confirmado para build» que a producto listo para producción.

La pregunta real para founders no es si Accord funciona técnicamente — funciona. La pregunta es si tu equipo puede operar con un feature que viene sin soporte oficial, sin benchmarks públicos, y con restricciones documentadas que podrían invalidar assumptions de diseño existentes. Para algunos workloads, especialmente aquellos que pagaron alto costo en协调 code application-side, vale la pena explorar. Para otros, especialmente multi-DC con requerimientos de latencia local, aún falta madurez.

El ecosistema de bases de datos distribuidas ha esperado cinco años por esta capacidad. Ahora que existe, la decisión es si tu startup puede absorber el riesgo operacional de trabajar con alpha versus mantener la arquitectura híbrida actual.