YugabyteDB y CockroachDB: bases distribuidas en 2025
Actualizado: 2026-05-03
En 2025 hablar de SQL distribuido ya no es hablar de promesas. 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.
Puntos clave
- PostgreSQL vertical cubre el 90 % de los casos: cambiar a SQL distribuido por razones de moda tiene coste real en latencia, operación y compatibilidad SQL.
- YugabyteDB reutiliza literalmente el procesador de consultas de PostgreSQL; CockroachDB reimplementa SQL desde cero — la brecha de compatibilidad es significativa.
- CockroachDB cambió a licencia propietaria en 2024; YugabyteDB mantiene Apache 2.0 para la versión comunidad — esto ha sido el factor de crecimiento más importante de Yugabyte en el último año.
- En escrituras replicadas en tres nodos dentro de una región, ambos rinden en decenas de miles de ops/s por nodo con latencias de 2 a 10 ms — claramente peor que Postgres en una sola máquina.
- Los tres casos con sentido claro para bases distribuidas son: escrituras multiregión simultáneas, volumen que supera la escala vertical, y tolerancia a fallos sin intervención humana crítica.
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 para escrituras, y una sola región como latencia base.
Cuando una aplicación necesita ir más allá, las opciones clásicas — particionar manualmente, sharding a nivel aplicación, réplicas con compromisos de consistencia — introducen complejidad que el equipo paga durante años. Ambas bases distribuidas 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 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 basada en RocksDB 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 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 JOINs 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. Para el contexto de despliegue, la integración con herramientas de observabilidad como Parca y Beyla es similar en ambas dado que exponen métricas estándar de PostgreSQL.
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, una vez agotada la escala vertical
- 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 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.
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.
El principio que guía la decisión es el mismo que aplica a cualquier infraestructura: elegir el sistema más simple que resuelva el problema real, no el más sofisticado que pueda imaginarse. La complejidad operativa de un sistema distribuido se paga en cada incidente, en cada actualización y en cada persona de guardia que tiene que entender el modelo de consistencia a las tres de la mañana.
