Diseñamos CockroachDB de forma equivocada y funciona

Descargo de responsabilidad Este artículo describe una decisión técnica cuestionable que, contra todo pronóstico, funcionó para nuestro caso particular. Es muy probable que falte contexto y que ingenieros con más experiencia encuentren una solución mejor, pero compartimos la historia porque puede servir de lección y advertencia.

La expectativa inicial era alta. Buscábamos una base de datos SQL distribuida que escalara horizontalmente y mantuviera consistencia, algo que encajara con nuestra plataforma SaaS. La promesa de una experiencia parecida a PostgreSQL con la escalabilidad de sistemas distribuidos nos resultó atractiva. Sin embargo, la realidad fue diferente y sorprendente.

Al empezar a evaluar CockroachDB experimentamos latencias inesperadas en su oferta cloud. Consultas simples tardaban más de dos segundos y la creación de tablas se demoraba casi dos minutos. Soporte técnico ofreció soluciones que no resolvieron el problema real y en ocasiones recomendó reinstalar el clúster o indicó que mientras algo no estuviera roto no era un problema. Eso nos llevó a ejecutar pruebas propias.

En nuestras pruebas reproducibles observamos que una instalación en una sola máquina pequeña ofrecía latencias mucho mejores que un clúster distribuido en teoría correctamente aprovisionado. Peor aún, las mediciones cross cloud resultaron ser más rápidas que las mismas dentro de una misma región en un proveedor. Estas cifras nos obligaron a cuestionar lo que creíamos saber sobre redes y diseño de sistemas.

Al indagar entendimos el coste inherente al diseño distribuido: cada escritura necesita consenso de la mayoría de nodos y las consultas pueden requerir saltos entre nodos hasta encontrar el leaseholder de los datos. Añadir más nodos aumentó la latencia. Eso tiene sentido para aplicaciones globales que necesitan supervivencia ante fallos regionales, pero para un servicio con clientes regionales y sensibilidad a la latencia, el precio en rendimiento fue inaceptable.

En lugar de rediseñar la arquitectura correctamente, implementar enrutamiento de consultas inteligente o usar réplicas de solo lectura, tomamos una decisión pragmática y de muy baja complejidad operativa. Coubicamos la aplicación y un nodo de la base de datos en la misma instancia. Cada instancia ejecuta el servidor de aplicación y un nodo de CockroachDB y la app se conecta a localhost:26257. Esa fue nuestra arquitectura simplificada.

Esta aproximación viola principios básicos de diseño: separación de capas, escalado independiente y aislamiento para mantenimiento. Aun así, dejó fuera una ronda de red de cada consulta en muchos casos. Si los datos están en el nodo local la respuesta es submilisegundo. Si no, solo hay un salto de red adicional para reenviar la petición al nodo correcto. Comparado con la ruta tradicional que puede incluir balanceador y varios nodos, eliminamos una latencia relevante por cada acceso.

No recomendamos esta solución. Sabemos que estamos acumulando riesgos: competencia por recursos entre base de datos y aplicación, comportamientos impredecibles durante compactaciones o backups, y supresión de ventajas del planificador distribuido. Nuestra respuesta ante problemas hasta ahora ha sido añadir más RAM y más instancias. Es barato a corto plazo, pero puede ser una trampa a largo plazo.

En la práctica la estrategia verticalizada nos ha funcionado. La latencia p99 mejoró, la carga operativa bajó y los clientes no notaron degradación. Aun así, creemos que lo correcto para la mayoría es elegir una arquitectura basada en necesidades: para muchos casos un PostgreSQL con replicación, una correcta configuración de CockroachDB por expertos o incluso mantener la oferta cloud puede ser la decisión adecuada.

En Q2BSTUDIO, empresa especializada en desarrollo de software, aplicaciones a medida y soluciones de inteligencia artificial, aprendemos de estas experiencias para aconsejar alternativas sanas y escalables. Si tu proyecto requiere una plataforma robusta y administrable, podemos ayudarte a diseñarla evitando este tipo de atajos. Para proyectos con necesidades de software a medida podemos proponer arquitecturas que equilibren rendimiento y resiliencia. Si la discusión pasa por dónde desplegar, optimizar o migrar, también ofrecemos servicios en la nube como servicios cloud aws y azure adaptados a cada caso.

Además de desarrollo a medida, en Q2BSTUDIO trabajamos en ciberseguridad, inteligencia de negocio, implementación de power bi, agentes IA y soluciones de ia para empresas. Esas capacidades nos permiten evaluar no solo el componente de base de datos sino todo el ecosistema: monitorización, seguridad, pipelines de datos y automatización de procesos para minimizar riesgos operativos.

Lecciones clave y recomendaciones prácticas si estás experimentando problemas similares Mantener la separación de responsabilidades a menos que tengas restricciones claras. Evaluar el patrón de acceso a datos antes de decidir replicación y topología. Probar con workloads representativos y en condiciones reales, incluyendo p99 y pruebas de fallos. Considerar soluciones más simples como PostgreSQL con replicación si la alta disponibilidad multinodo no es prioritaria. Contar con especialistas en distribuidos antes de adoptar una base de datos cuyos costes de coherencia pueden penalizar mucho el rendimiento.

Si te interesa que analicemos tu arquitectura o que diseñemos una solución que incluya automatización, inteligencia artificial o estrategias de observabilidad y seguridad, en Q2BSTUDIO disponemos de experiencia para transformar requisitos en soluciones productivas.

Resumen final No estamos diciendo que nuestra aproximación sea la correcta para nadie más. Es un atajo que nos dio resultados en un contexto concreto y controlado, con cargas y patrones que jugaron a nuestro favor. En la mayoría de casos debe prevalecer el diseño formal, la separación de capas y la correcta parametrización del sistema distribuido. Si quieres evitar sorpresas y obtener una arquitectura pensada para crecimiento, podemos colaborar contigo.