Hace cinco años hablar de SQL distribuido era hablar de promesas. Google Spanner era la referencia teórica, inaccesible para la mayoría fuera de Google Cloud, y las alternativas abiertas estaban en fase temprana. En 2025 el panorama ha cambiado: YugabyteDB y CockroachDB son dos motores maduros, en producción en empresas grandes, con años de rodaje y comunidad activa. Para equipos que diseñan plataformas nuevas, elegir entre una de ellas o seguir con Postgres tradicional es una decisión frecuente y no trivial.
El problema que ambas resuelven
PostgreSQL vertical ha sido durante años la respuesta más eficiente a la mayoría de necesidades de bases relacionales. Corre en una máquina, suele tener una réplica para lectura, y escala vertical añadiendo núcleos o disco. Esta arquitectura cubre el noventa por ciento de los casos, pero tiene un techo claro: una sola máquina física, un solo servidor como punto de fallo, y una sola región como latencia base. Cuando una aplicación necesita ir más allá, las opciones clásicas (particionar manualmente, shardings a nivel aplicación, réplicas con compromisos de consistencia) introducen complejidad que el equipo paga durante años.
Ambas, YugabyteDB y CockroachDB, prometen lo mismo a alto nivel: SQL compatible, transacciones distribuidas ACID, replicación síncrona entre nodos, tolerancia a fallos sin intervención manual, y escalado horizontal añadiendo nodos. La diferencia está en cómo lo consiguen.
Arquitecturas que parten de sitios distintos
CockroachDB, creada por Cockroach Labs y publicada en 2015, parte de un diseño inspirado en Google Spanner. Su capa de almacenamiento está en Go, con RocksDB como motor de disco y ahora su propio motor Pebble. Cada tabla se divide automáticamente en rangos de filas, cada rango se replica mediante Raft entre tres nodos por defecto, y las transacciones distribuidas usan un protocolo basado en tiempos sincronizados. El dialecto SQL es compatible con el protocolo PostgreSQL a nivel de cable, pero la implementación es propia.
YugabyteDB, creada por antiguos ingenieros de Facebook y publicada como código abierto en 2019, toma un camino distinto. Tiene una capa de almacenamiento llamada DocDB también basada en RocksDB y con replicación Raft por tablets, pero encima reutiliza el procesador de consultas de PostgreSQL. Esto es clave: la capa SQL de YugabyteDB es literalmente código de Postgres modificado. Eso significa que la mayoría de extensiones, funciones, procedimientos almacenados y comportamientos específicos funcionan igual que en Postgres.
Esta diferencia tiene consecuencias prácticas grandes. En CockroachDB, cada funcionalidad de Postgres que necesitas tiene que estar reimplementada por el equipo de Cockroach Labs. Llevan años acercándose, pero siguen faltando extensiones como PostGIS con todas sus funciones, timescaledb, pg_trgm, o comportamientos sutiles como ciertos tipos de índice parciales. En YugabyteDB esas cosas funcionan o tienen una brecha mucho más pequeña porque aprovechan directamente el código de Postgres.
Rendimiento y latencia
El rendimiento de estas bases es muy dependiente del tipo de carga. En escrituras simples replicadas en tres nodos dentro de una misma región, ambas rinden en el orden de decenas de miles de operaciones por segundo por nodo, con latencias típicas entre dos y diez milisegundos. Esto es significativamente peor que un Postgres no distribuido en una sola máquina, que puede dar cientos de miles de escrituras por segundo con latencia bajo el milisegundo. El coste de la distribución es real y hay que asumirlo.
Donde estas bases brillan es cuando necesitas resistir fallos, repartir carga entre varias regiones o escalar por encima de lo que una sola máquina da. La latencia absoluta sigue siendo peor que un Postgres local, pero la capacidad agregada y la resiliencia compensan: escribir en una base tradicional cuando el primario se cae puede significar minutos de caída, mientras en estos motores la escritura se mantiene sin interrupción con dos de tres nodos disponibles. Ambas permiten servir lecturas desde la réplica más cercana al cliente, y permiten opcionalmente lecturas con bounded staleness para ganar latencia a cambio de un pequeño desfase.
Compatibilidad SQL en la práctica
Para una aplicación que ya usa Postgres, la pregunta crítica al evaluar estas bases es cuánto código hay que reescribir. YugabyteDB tiene ventaja aquí por su reutilización del parser y ejecutor de Postgres: la mayoría de esquemas, consultas y procedimientos funcionan sin cambios, aunque hay compromisos en tipos de índice y en algunas funciones de bloqueo. CockroachDB ha hecho un trabajo enorme acercando su dialecto al de Postgres, pero quedan diferencias que pueden morder: ciertos JOIN complejos se comportan distinto, algunas funciones agregadas no están, y los procedimientos almacenados llegaron tarde. Las dos soportan el protocolo de cable de Postgres y los drivers estándar y herramientas de migración funcionan.
Licencias y modelo de negocio
Aquí la comparación se pone interesante. CockroachDB cambió en 2024 de licencia BSL a licencia propietaria, eliminando la opción gratuita para uso empresarial; la Core Edition sigue open source pero con limitaciones importantes para entornos con más de un cluster. YugabyteDB mantiene su licencia Apache 2.0 sin restricciones para la versión comunidad, que incluye la mayoría de funcionalidades. Esta diferencia empuja claramente a equipos que valoran la licencia abierta pura hacia YugabyteDB, y ha sido probablemente el factor de crecimiento más importante del proyecto en el último año. Ambas ofrecen servicios gestionados en la nube (YugabyteDB Aeon, CockroachDB Cloud) y funcionan bien en Kubernetes con operadores oficiales.
Cuándo compensa una base distribuida
Mi lectura después de ver varios despliegues es que estas bases resuelven problemas reales, pero muchas veces se adoptan prematuramente. Postgres en una máquina bien dimensionada cubre las necesidades de la mayoría de empresas durante muchos años; cambiar a SQL distribuido solo porque suena moderno es cambiar un problema que no tienes por tres que sí vas a tener: operación más compleja, latencia peor, y compromisos en SQL que no son evidentes desde fuera.
Los casos donde la migración tiene sentido claro son tres: necesidades de multiregión con escrituras desde varias regiones al mismo tiempo, volúmenes que han crecido por encima de lo que una sola máquina da de sí una vez agotada la escala vertical, y requisitos de continuidad donde la tolerancia a fallos sin intervención humana es crítica. Para aplicaciones nuevas con proyección clara de crecimiento global, arrancar directamente con una base distribuida puede tener sentido, pero exige equipo con experiencia específica.
Cómo pensar la decisión entre las dos
Si la decisión es entre YugabyteDB y CockroachDB, en 2025 yo me inclino por YugabyteDB para la mayoría de casos, por cuatro razones: compatibilidad con Postgres más profunda, licencia abierta firme, ecosistema cercano al mundo Postgres mayoritario, y funcionalidades antes ausentes ya cerradas. CockroachDB sigue siendo una opción sólida si tu aplicación ya está escrita contra su dialecto o si tu caso encaja bien con su modelo serverless en la nube, y tiene ventajas en despliegues con geo-particionamiento complejo.
Fuera de esa comparación, merece la pena recordar que Neon, Supabase y Crunchy Bridge han avanzado mucho en ofrecer Postgres serverless con replicación multizona sin saltar a SQL distribuido completo. Para muchos casos que antes empujaban hacia Yugabyte o Cockroach, hoy Postgres gestionado con réplicas geográficas bien diseñadas es suficiente. La pregunta de “base distribuida sí o no” tiene ahora un matiz intermedio que no tenía en 2020.
