SQL distribuido: cuándo usar Spanner, CockroachDB y YugabyteDB

Qué significa SQL distribuido

SQL distribuido es una arquitectura de base de datos relacional que reparte los datos y el procesamiento de transacciones entre varias máquinas, pero presenta a las aplicaciones una única base de datos SQL lógica. Conserva tablas, joins, índices, restricciones y transacciones ACID, y añade particionado automático, replicación y recuperación ante fallos.

Un sistema suele pertenecer a esta categoría cuando reúne estas características:

• Un esquema relacional y una interfaz de consultas SQL
• Escalado horizontal entre nodos de base de datos
• Consistencia transaccional entre particiones
• Replicación y conmutación por error automáticas
• Funcionamiento coordinado como una sola base de datos lógica

La definición importa porque una base de datos no pasa a ser SQL distribuido solo por añadir réplicas de lectura a PostgreSQL o MySQL. Una primaria con réplicas sigue enviando las escrituras a un servidor principal. El sharding gestionado por la aplicación distribuye las escrituras, pero obliga a la aplicación a decidir dónde vive cada registro y cómo se comporta el trabajo entre shards. SQL distribuido traslada gran parte de esa responsabilidad a la base de datos.

La posición entre un RDBMS convencional y NoSQL

SQL distribuido combina el modelo de programación relacional de un RDBMS convencional con el diseño escalable asociado a los almacenes de datos distribuidos. Los despliegues tradicionales de PostgreSQL y MySQL funcionan bien mientras una instancia primaria pueda gestionar la carga de escritura y un fallo regional no exija seguir escribiendo desde otro lugar. Las réplicas de lectura, la caché, el pool de conexiones y mejores índices pueden ampliar ese modelo durante años.

Muchas bases de datos NoSQL facilitaron la distribución limitando los joins, las transacciones o las garantías de consistencia. Esas decisiones siguen teniendo sentido para cargas como grandes flujos de eventos, cachés desechables y registros que rara vez participan en transacciones de varias filas. Un clúster relacional asume más coordinación porque las aplicaciones esperan que las restricciones y las transacciones sigan siendo válidas después de repartir los datos entre nodos.

La diferencia práctica es quién asume la complejidad. Con sharding manual, los equipos de aplicación implementan el enrutamiento, reequilibran los datos, coordinan los cambios de esquema y gestionan operaciones que tocan varios shards. Con SQL distribuido, la base de datos proporciona esos mecanismos, aunque los equipos técnicos aún deben diseñar esquemas y consultas para un sistema conectado por red.

Los problemas que busca resolver

SQL distribuido está pensado para aplicaciones cuya disponibilidad, ubicación geográfica o crecimiento de escrituras ya supera una arquitectura con una sola primaria. Algunos casos habituales son un servicio SaaS global, un sistema de reservas que no puede vender de más y un libro mayor financiero cuyas reglas deben sobrevivir a fallos de nodos.

Puede eliminar la necesidad de sharding en la aplicación y reducir la dependencia de un único lugar de escritura. También puede colocar los datos cerca de los usuarios o dentro de jurisdicciones autorizadas. Estas ventajas tienen un precio: más réplicas, más tráfico de red, más coordinación y modos de fallo que no existen en un solo servidor.

Una base de datos relacional gestionada y convencional sigue siendo la mejor opción por defecto cuando la carga cabe cómodamente en una región. SQL distribuido justifica su coste cuando el sharding personalizado, la conmutación regional por error o los controles geográficos de datos se convertirían por sí mismos en un gran sistema de ingeniería.

Cómo funciona SQL distribuido internamente

SQL distribuido divide los datos en particiones replicadas y coordina los cambios mediante consenso y protocolos de transacciones distribuidas. La base de datos oculta gran parte de esa maquinaria tras SQL, pero su comportamiento sigue influyendo en la latencia, el rendimiento, el diseño del esquema y la respuesta ante incidentes.

Las particiones determinan dónde viven los registros

Un clúster divide sus tablas lógicas en unidades más pequeñas que pueden moverse de forma independiente entre nodos. Spanner suele llamar splits a estas unidades, CockroachDB usa ranges y YugabyteDB usa tablets. Cada unidad cubre una parte del espacio de claves de una tabla o un índice.

Los límites de las particiones pueden seguir rangos, hashes o reglas geográficas explícitas. Un rango ordenado por identificador de cliente facilita escanear registros relacionados, pero un identificador que aumenta continuamente puede dirigir las nuevas escrituras a una partición. La distribución hash reparte las escrituras de forma más uniforme, aunque puede complicar los escaneos ordenados o la ubicación por cliente. Muchos esquemas de producción combinan un identificador de cliente con otro valor para mantener los datos relacionados accesibles sin concentrar todas las escrituras en un lugar.

Los índices secundarios necesitan su propio almacenamiento distribuido. Por ello, escribir una fila puede actualizar la tabla base y varias entradas de índice en particiones distintas. Un índice que era barato en un solo servidor puede generar trabajo adicional de consenso y tráfico de red en un clúster.

La replicación y el consenso protegen cada partición

Cada partición suele tener varias réplicas, y un grupo de consenso decide la secuencia aceptada de cambios. CockroachDB y YugabyteDB usan replicación basada en Raft. Spanner usa replicación basada en Paxos junto con su infraestructura de tiempo.

Un líder o leaseholder coordina las escrituras de un grupo de réplicas. El sistema registra un cambio en suficientes réplicas para formar quórum antes de considerarlo confirmado. Si desaparece un nodo, los miembros supervivientes pueden elegir o designar otro coordinador mientras siga disponible un quórum.

El quórum es un requisito matemático, no la promesa de que todos los fallos sean inocuos. Un grupo de tres réplicas suele tolerar una réplica no disponible. Si se pierden dos miembros, la copia restante no puede aceptar escrituras con seguridad porque no puede demostrar que otra mayoría no haya avanzado en otro lugar. La ubicación entre dominios de fallo importa tanto como el número de réplicas.

Las transacciones distribuidas coordinan varias particiones

Una transacción que toca una sola partición puede terminar con relativamente poca coordinación. Una transacción que involucra varias particiones necesita una decisión de commit común para que todos los participantes apliquen sus escrituras o las aborten.

El protocolo exacto varía según el producto, pero el trabajo suele incluir leer o bloquear versiones relevantes, validar cambios concurrentes, replicar intents o registros provisionales y finalizar el commit. Las transacciones largas amplían la ventana de conflictos. Los lotes grandes pueden involucrar a muchos grupos de consenso y provocar picos de latencia aunque cada sentencia individual parezca sencilla.

Por eso importa diseñar transacciones pensando en la red. Agrupa filas relacionadas bajo prefijos de partición compatibles cuando la base de datos admita esa estrategia. Mantén las transacciones cortas, evita esperar a servicios externos mientras una transacción está abierta y no cargues miles de registros no relacionados en una unidad atómica sin medir el efecto.

El tiempo y el orden requieren mecanismos explícitos

Los nodos distribuidos no comparten un reloj de pared perfectamente sincronizado, por lo que cada producto necesita una forma de ordenar transacciones. Spanner usa los límites de incertidumbre de TrueTime y espera de commit para ofrecer consistencia externa. Otros sistemas pueden combinar relojes físicos con componentes lógicos, seguimiento de dependencias y protocolos de transacción.

La coordinación de relojes afecta operaciones como la ejecución serializable, las lecturas de seguidores y las instantáneas. Las aplicaciones deben usar las marcas de tiempo de transacción de la base de datos en lugar de asumir que las marcas creadas por servidores de aplicación independientes establecen un orden global fiable.

La localidad controla el recorrido de red

La configuración de localidad decide dónde se sitúan las réplicas y qué región coordina las escrituras de un registro. Las lecturas pueden ser rápidas cuando una réplica adecuada está cerca de quien llama. Una escritura con orden fuerte aún debe llegar a las réplicas necesarias para el quórum, así que su latencia refleja la topología elegida.

Una buena ubicación sigue a la carga de trabajo, no a un diagrama de la empresa. Si la mayoría de las escrituras de un cliente de la UE proceden de Europa, situar allí su coordinador de escritura evita un viaje intercontinental al inicio de cada transacción. Un registro compartido globalmente, como un contador actualizado por todas las regiones, no puede estar local para todos los escritores y puede convertirse en un punto de contención.

Cuándo SQL distribuido es la opción correcta

SQL distribuido es adecuado cuando la resiliencia geográfica, la capacidad de escritura horizontal o la corrección entre particiones importan lo suficiente como para justificar el coste continuo de coordinación. Una empresa grande no lo necesita automáticamente, y un producto pequeño puede necesitarlo si su promesa de negocio incluye disponibilidad regional estricta.

Condiciones que justifican una evaluación

Conviene realizar una evaluación seria cuando se cumplen varias de estas condiciones:

• El servicio debe continuar tras una caída de zona o región
• La demanda de escritura se acerca al límite práctico de una base de datos primaria
• El sharding manual consumiría mucho tiempo de ingeniería de aplicación
• Las transacciones deben seguir siendo correctas entre nodos o ubicaciones
• Los registros requieren una ubicación geográfica exigible

Estas condiciones deben respaldarse con cifras. Define el objetivo de tiempo de recuperación, el objetivo de punto de recuperación, la latencia de transacción, el pico de escrituras y los dominios de fallo. Una petición vaga de escala global no basta para elegir arquitectura.

Tener usuarios regionales por sí solo no es una razón decisiva. Una aplicación centrada en contenido puede colocar servidores web y cachés cerca de los usuarios y mantener una sola región de base de datos. Las réplicas de lectura pueden servir la navegación regional si se aceptan resultados ligeramente antiguos. El caso se refuerza cuando usuarios de varias ubicaciones deben realizar escrituras de baja latencia sobre datos relacionados.

Condiciones que favorecen una base de datos más simple

Un servicio relacional convencional suele ser preferible cuando el tráfico es moderado, las escrituras proceden de una región y la recuperación puede incluir una promoción planificada de base de datos. Ofrece herramientas maduras, amplia compatibilidad con extensiones, depuración familiar y una factura de infraestructura menor.

Los requisitos de latencia estrictos también pueden favorecer una primaria regional. Una escritura local y duradera puede completarse mucho más rápido que una escritura de quórum que cruza regiones lejanas. Los sistemas con mucha analítica normalmente deben separar las transacciones operativas de los escaneos largos, en lugar de esperar que el mismo clúster destaque en ambos.

La capacidad del equipo importa. Los servicios gestionados reducen el trabajo de hardware, parches y operación del plano de control, pero no eliminan la contención del esquema, los reintentos de transacciones, la planificación de consultas, la gestión de capacidad ni la gestión de incidentes desde la aplicación. Si un equipo no tiene tiempo para probar el comportamiento ante fallos, adoptar una base de datos distribuida puede aumentar el riesgo.

Un umbral de decisión basado en las alternativas

La justificación más sólida aparece cuando la alternativa ya es complicada. Si los equipos están a punto de crear enrutamiento de clientes, mapas de shards, reglas para transacciones entre shards, procedimientos de promoción regional y herramientas de migración separadas, merece la pena evaluar a fondo una base de datos que ofrezca esas funciones.

Si la alternativa es una instancia gestionada de PostgreSQL con una réplica de lectura y copias de seguridad probadas, una migración exige pruebas claras. Primero mide el sistema actual. La saturación de CPU puede deberse a una consulta ineficiente, una gestión deficiente de conexiones, índices excesivos o la ausencia de caché, no a la necesidad de escrituras horizontales.

Consistencia, disponibilidad y latencia

SQL distribuido suele conservar la consistencia transaccional durante fallos rechazando operaciones que no pueden alcanzar el quórum necesario. Este comportamiento protege el estado confirmado, pero implica que algunas solicitudes pueden fallar o esperar durante una partición de red.

CAP describe el comportamiento ante fallos

El teorema CAP se aplica cuando se interrumpe la comunicación entre partes del clúster. Para los datos afectados, un sistema no puede garantizar simultáneamente consistencia linealizable y respuestas correctas desde cada lado aislado. Una base de datos orientada a la consistencia permite continuar al lado con quórum y rechaza escrituras inseguras en los demás.

CAP no explica la latencia durante la operación normal. Incluso cuando todos los enlaces funcionan, las réplicas deben comunicarse. La decisión de ingeniería incluye qué ocurre durante una partición y cuánta coordinación acepta la aplicación cuando todo está sano.

Una aplicación debe gestionar explícitamente los resultados no disponibles. Los tiempos de espera, los errores de transacción reintentables y la pérdida temporal de una región de escritura son posibilidades normales. Devolver éxito desde dos regiones aisladas sería peor para un saldo o una reserva, porque la reconciliación quizá no tendría una respuesta automática válida.

Las lecturas fuertes y las intencionadamente antiguas son distintas

Una lectura fuerte observa un estado de la base de datos coherente con la garantía de orden solicitada. Algunos productos también ofrecen lecturas de seguidores o de antigüedad acotada, que intercambian frescura por menor latencia y menos trabajo en el coordinador de escritura.

La elección debe seguir al campo leído. Una descripción de producto puede tolerar una réplica algo antigua. Una contraseña recién cambiada, el saldo actual de una cuenta o el inventario restante deben usar una ruta fuerte o consistente con la sesión. Las aplicaciones no deben marcar todas las lecturas como antiguas para ganar velocidad y luego reconstruir la corrección en código de servicio.

El comportamiento de leer las propias escrituras necesita pruebas con el driver y la capa de enrutamiento reales. Tras una actualización, la siguiente solicitud puede llegar a otro servidor de aplicación o endpoint de base de datos. Puede ser necesario usar tokens de sesión, límites de transacción o una configuración de lectura fuerte para garantizar que la persona usuaria vea el cambio aceptado.

El aislamiento controla los resultados concurrentes

El aislamiento de transacciones determina qué anomalías pueden producir las transacciones concurrentes. El aislamiento serializable busca que las transacciones completadas parezcan haberse ejecutado una por una, aunque la base de datos las ejecute simultáneamente.

La ejecución serializable puede abortar a un participante cuando las operaciones concurrentes no pueden ordenarse de forma segura. Ese aborto protege contra un mal resultado, no indica corrupción de la base de datos. Las aplicaciones necesitan reintentos acotados alrededor de toda la transacción, incluidas todas las lecturas que influyeron en sus escrituras.

Los reintentos deben ser idempotentes fuera de la base de datos. Si el código envía un correo o llama a un proveedor de pagos antes de que la transacción se haya confirmado con certeza, un reintento puede repetir el efecto secundario. Registra un evento outbox dentro de la transacción de base de datos, confírmala y deja que un proceso aparte entregue la acción externa.

La distancia impone un mínimo a la latencia de escritura

Una transacción entre regiones no puede terminar más rápido que los mensajes requeridos por su protocolo. Un viaje de ida y vuelta de 80 milisegundos entre miembros del quórum añade tiempo real antes de contar la ejecución de consultas, el mantenimiento de índices, el trabajo de la aplicación y las colas.

El patrón caro suele ser realizar varias transacciones secuenciales en una acción de usuario. Si el checkout hace una inserción de pedido, una reserva de inventario, una actualización del estado de pago y una escritura de auditoría como cuatro commits bloqueantes, el coste de red se acumula. Combinar cambios de base de datos que comparten un resultado atómico puede eliminar viajes innecesarios, mientras que las llamadas externas de pago deben quedar fuera de una transacción abierta.

Mide percentiles de latencia en lugar de promedios. Los cambios de liderazgo, la contención, las pausas de almacenamiento y los reintentos aparecen en la cola. Un diseño que cumple su objetivo de mediana, pero falla en el percentil 99 durante un reequilibrio normal, puede producir fallos visibles para los usuarios.

Comparativa de Spanner, CockroachDB y YugabyteDB

Spanner, CockroachDB y YugabyteDB resuelven problemas de distribución similares, pero difieren en su modelo de despliegue, compatibilidad, implementación de transacciones y supuestos operativos. Elegir entre ellos exige probar el comportamiento de la aplicación, no decidir solo por la etiqueta compartida de SQL.

Spanner encaja en una estrategia gestionada de Google Cloud

Spanner encaja en organizaciones dispuestas a usar una base de datos gestionada de Google Cloud y a diseñar en torno a su dialecto, topología y modelo operativo. TrueTime respalda transacciones externamente consistentes, lo que significa que las transacciones confirmadas respetan el orden de tiempo real dentro de la semántica documentada.

Su dialecto PostgreSQL puede reducir diferencias de sintaxis SQL, pero un dialecto no equivale a una compatibilidad completa con PostgreSQL. Las extensiones, funciones administrativas, catálogos del sistema, tipos de datos, drivers y supuestos del ORM aún requieren verificación. Los equipos deben inventariar todas las dependencias de base de datos antes de considerar portable una aplicación existente.

Spanner merece especial atención cuando el sistema deseado ya depende de la identidad, red, observabilidad y controles regionales de Google Cloud. El modelo gestionado elimina la administración de nodos de base de datos, aunque el diseño de esquemas, la optimización de consultas, las cuotas, la gestión de costes y la recuperación de la aplicación siguen siendo responsabilidad del cliente.

CockroachDB encaja en aplicaciones distribuidas orientadas a PostgreSQL

CockroachDB encaja en equipos que quieren acceso de aplicación al estilo PostgreSQL mientras distribuyen los datos transaccionales entre ranges. Usa aislamiento serializable por defecto, por lo que las aplicaciones deben reintentar correctamente las transacciones rechazadas por contención o conflictos de orden.

La compatibilidad debe probarse en las capas de migración, driver y ORM. Las extensiones de PostgreSQL y comportamientos especializados pueden faltar o ser distintos. Las consultas que dependen de planes de ejecución de un solo nodo también pueden comportarse de otra manera después de dividir tablas e índices entre ranges.

El movimiento de ranges y el reequilibrio automático simplifican los cambios de capacidad, pero una mala elección de clave primaria aún puede producir ranges calientes. Las abstracciones multirregión ayudan a expresar la localidad de las tablas, aunque quienes desarrollan deben decidir qué registros son regionales, cuáles globales y dónde se coordinan las escrituras.

YugabyteDB encaja en requisitos de YSQL y APIs mixtas

YugabyteDB encaja en aplicaciones que valoran una interfaz relacional compatible con PostgreSQL y pueden beneficiarse de su API independiente compatible con Cassandra. YSQL ofrece tablas relacionales y transacciones distribuidas, mientras que YCQL sigue otro modelo de datos y no debe tratarse como otra vía para cada operación de YSQL.

Su capa de almacenamiento distribuye los datos mediante tablets. El diseño de tablas, la división de tablets, la ubicación de índices y el alcance de las transacciones influyen en cómo se reparte el trabajo por el clúster. Las aplicaciones PostgreSQL siguen necesitando pruebas de compatibilidad de extensiones, funciones, herramientas y comportamiento del planificador.

Contar con distintos enfoques de despliegue puede encajar con políticas de infraestructura que exigen controlar la ubicación. En un entorno autogestionado, ese control transfiere al cliente la responsabilidad operativa: actualizaciones, procedimientos de reparación, capacidad, observabilidad, certificados, copias de seguridad y pruebas de fallo necesitan responsables.

Una prueba útil de producto usa evidencia de la aplicación

Una comparación útil ejecuta la misma carga de trabajo representativa en cada producto viable. Prueba la creación de esquemas, migraciones, SQL generado por el ORM, reintentos de transacciones, restauración de copias de seguridad, conmutación por error, eventos de escalado y las consultas de mayor volumen.

No compares solo el máximo de transacciones por segundo. Registra latencia p50, p95 y p99, tasas de conflicto y reintento, bytes transferidos entre regiones, amplificación de almacenamiento, tiempo de restauración y esfuerzo del operador durante un incidente simulado. La mejor opción es la que cumple los objetivos de corrección y recuperación con un coste y una carga operativa aceptables.

SaaS global con usuarios regionales

Una aplicación SaaS global se beneficia de SQL distribuido cuando los clientes necesitan ubicación regional de datos y acceso transaccional sin pilas de base de datos separadas para cada geografía. El diseño funciona mejor cuando la pertenencia a un cliente es explícita en el esquema y la mayoría de las transacciones se mantienen dentro de un cliente.

La localidad del cliente debe seguir los contratos y el tráfico

Un identificador de cliente puede guiar la ubicación para que los registros europeos permanezcan en ubicaciones europeas autorizadas, mientras que los registros de otro cliente se quedan en su país o región contratados. Así se mantiene un esquema lógico único y se permiten políticas físicas distintas.

Las reglas de ubicación deben abarcar más que la tabla base. Las entradas de índices, flujos de cambios, datos temporales, copias de seguridad y registros exportados pueden contener información regulada. Una política que fija filas, pero envía un índice secundario global a otro lugar, puede incumplir el límite previsto.

El aislamiento de clientes también afecta al rendimiento. Un cliente grande puede saturar una partición compartida o dominar un nodo. Puede ser necesario aplicar hash o subparticiones dentro de ese cliente, pero preservando el acceso eficiente a transacciones con alcance de cliente.

Las lecturas regionales necesitan una política de frescura explícita

Los paneles con muchas lecturas pueden usar réplicas cercanas cuando se aceptan datos ligeramente retrasados. Los cambios de cuenta, decisiones de autorización y pantallas de confirmación después de una transacción necesitan un comportamiento más fuerte. Clasifica las rutas de consulta según su necesidad de frescura en vez de adoptar una configuración global única.

La ubicación de escritura debe seguir al escritor habitual de cada cliente. Si el personal de un cliente trabaja principalmente en Singapur, coordinar sus escrituras en otro continente crea una latencia evitable. Un procedimiento de migración de cliente debe actualizar la ubicación sin perder escrituras, incumplir la residencia de datos ni dejar las cachés de la aplicación apuntando a ubicaciones antiguas.

El código global de la aplicación debe tolerar movimiento

Los líderes se mueven, los nodos se reinician y el enrutamiento cambia durante el mantenimiento. Los drivers necesitan tiempos de espera sensatos, políticas de reintento, renovación de conexiones y lógica para reiniciar transacciones. Los reintentos deben usar una variación aleatoria y un límite para que un clúster sobrecargado no reciba de inmediato una oleada sincronizada de solicitudes repetidas.

La monitorización debe separar la latencia de usuario por región y clase de cliente. Un promedio global puede ocultar que un grupo distante de clientes paga varios viajes adicionales por red. Los identificadores de trazas que conectan los tramos de API con las sentencias de base de datos facilitan encontrar errores de localidad.

Flujos financieros y libros mayores

Los flujos financieros se benefician cuando las restricciones y transacciones de base de datos hacen cumplir las reglas del libro mayor ante fallos y solicitudes concurrentes. La distribución no crea contabilidad correcta por sí sola, así que el esquema debe expresar las reglas que no se pueden incumplir.

Un libro mayor debe conservar una secuencia auditable de asientos

Un libro mayor orientado a anexos registra cada movimiento como asientos, en lugar de reemplazar repetidamente un saldo sin historial. Cada asiento debe tener un identificador de transacción estable, cuentas, importes, moneda, marca de tiempo de negocio y metadatos de creación. Las reglas de partida doble deben comprobarse antes del commit para que débitos y créditos se equilibren en la unidad de contabilización.

Un saldo en caché puede acelerar las lecturas, pero debe cambiar en la misma transacción que los asientos o tratarse claramente como dato derivado. Los procesos de conciliación deben comparar los totales derivados con los asientos de origen e informar de diferencias sin reescribir silenciosamente el historial.

Rara vez se necesita un orden global para todas las cuentas. Las transacciones que afectan a una cuenta o a un par de transferencia necesitan un orden coherente, mientras que las cuentas no relacionadas pueden continuar a la vez. Diseñar en torno a ese límite reduce la contención frente a una sola secuencia global o fila de liquidación.

La idempotencia hace seguros los reintentos

Las APIs de pago, colas y webhooks reintentan después de tiempos de espera, así que cada operación de negocio necesita una clave de idempotencia estable. Impón la unicidad dentro del alcance correcto, como un comercio o una cuenta, y crea el registro de pago y los asientos contables en una sola transacción de base de datos.

CREATE TABLE payment_attempts (
    account_id UUID NOT NULL,
    idempotency_key TEXT NOT NULL,
    provider_reference TEXT,
    status TEXT NOT NULL,
    created_at TIMESTAMPTZ NOT NULL,
    PRIMARY KEY (account_id, idempotency_key)
);

Si dos procesos envían la misma operación, la restricción única decide qué inserción tiene éxito. El proceso que pierde debe leer el registro existente y devolver su resultado establecido. No debe crear un segundo cargo del proveedor solo porque se reintentó una transacción de base de datos.

Las llamadas externas requieren un límite de transacción

Una base de datos no puede hacer commit atómico con un proveedor de pagos no relacionado, salvo que ambos participen en un protocolo especializado de coordinación, algo que la mayoría de las APIs públicas no hacen. Mantén la llamada de red fuera de la transacción de base de datos y modela el flujo con estados explícitos como pendiente, autorizado, capturado, fallido y revertido.

Un outbox transaccional puede publicar cambios confirmados a procesos posteriores. Los consumidores deben eliminar duplicados mediante el identificador de evento porque un mensaje puede entregarse más de una vez. Esto permite un procesamiento recuperable sin afirmar que existe una única transacción imposible entre todos los servicios.

Las cuentas calientes requieren un diseño específico para la carga

Las nóminas, liquidaciones de marketplaces y grandes comercios pueden concentrar escrituras en una cuenta. Añadir nodos de base de datos no divide entre ellos una única fila en conflicto. Las opciones incluyen particiones de asientos inmutables, acumuladores por periodo, contabilización en cola para una cuenta o una jerarquía de subcuentas cuidadosamente definida.

Prueba la distribución real del sesgo. El tráfico sintético uniforme puede hacer que un clúster parezca preparado mientras un comercio de producción provoca conflictos serializables repetidos. La corrección es prioritaria, pero el modelo de datos debe exponer concurrencia segura cuando las reglas contables lo permitan.

Inventario, reservas y asignaciones

Los sistemas de inventario y reservas necesitan una transacción de asignación autorizada cuando varias personas pueden reclamar el mismo recurso escaso. Las lecturas rápidas de disponibilidad mejoran la navegación, pero solo la ruta de commit puede decidir quién recibe la última unidad.

Las escrituras condicionales evitan vender de más

Una actualización condicional puede reservar existencias solo cuando quedan suficientes. El número de filas afectadas indica a la aplicación si la asignación tuvo éxito.

UPDATE inventory
SET available = available - 1
WHERE sku = $1
  AND available > 0;

Esta sentencia debe compartir una transacción con el registro de reserva. Leer la disponibilidad primero y disminuirla después crea una condición de carrera salvo que el nivel de aislamiento y el manejo de predicados protejan la decisión. Las restricciones de base de datos deben rechazar las cantidades negativas como capa adicional de seguridad.

Para asientos asignados, una restricción única sobre el evento y el identificador de asiento deja una sola reserva ganadora. El inventario hotelero suele modelarse por noche de habitación o fecha de pool de inventario para que estancias superpuestas no reclamen la misma capacidad. La unidad correcta de contención procede de la regla de negocio.

Las retenciones separan la asignación del pago

Una retención temporal reserva inventario mientras avanza el pago o la confirmación de la persona usuaria. Guarda su momento de expiración y estado, y conviértela en una reserva confirmada mediante una transacción condicional. Un proceso de expiración solo debe liberar retenciones que sigan activas, porque la confirmación y la expiración pueden competir.

El retraso de reloj no basta para garantizar la liberación. Los procesos pueden detenerse, las colas retrasarse y las regiones fallar. Las consultas que calculan el inventario vendible deben tener en cuenta de forma coherente el estado expirado, mientras que los procesos de reparación recuperan retenciones omitidas.

La duración de una retención es una decisión de producto y capacidad. Una retención de diez minutos puede ser razonable para checkout, pero puede bloquear una parte importante del inventario escaso durante un pico. Mide el abandono y el tiempo de finalización del pago antes de fijarla.

La contención extrema no escala linealmente

Miles de compradores compitiendo por una fila no pueden paralelizarse añadiendo réplicas. Cada disminución correcta debe ordenarse frente a las demás. Los controles de admisión, una cola, cubos de existencias o cuotas regionales preasignadas pueden proteger la base de datos durante un lanzamiento.

Las cuotas regionales reducen la coordinación, pero cambian la semántica. Si Europa tiene unidades sin usar mientras otra región se agota, el sistema necesita una forma segura de transferir cuota o aceptar un desequilibrio temporal. Usa este patrón solo cuando el negocio pueda definir cómo se reconcilia la capacidad regional.

Alta disponibilidad y recuperación ante desastres

SQL distribuido puede mantener el servicio ante determinados fallos de infraestructura cuando la ubicación de las réplicas, la capacidad sobrante y el comportamiento de la aplicación se ajustan a un objetivo de servicio definido. La replicación por sí sola no garantiza ese resultado.

Los SLO deben especificar dominios de fallo

Un objetivo de disponibilidad necesita una carga de trabajo y un escenario de fallo. Define si el servicio debe sobrevivir a un nodo, una zona de disponibilidad o una región completa. Indica la tasa de error y la latencia aceptables durante el evento, no solo después de recuperarse.

Un clúster de tres réplicas en un solo edificio tiene un perfil de riesgo distinto de tres réplicas en zonas independientes. Una topología multirregión protege frente a un evento más amplio, pero introduce trayectos de quórum más largos y necesita suficiente capacidad restante para absorber el tráfico cuando desaparece una ubicación.

El objetivo de tiempo de recuperación define la rapidez con que debe volver el servicio. El objetivo de punto de recuperación define cuántos datos confirmados se pueden perder. La replicación síncrona por quórum puede respaldar una meta de cero pérdida de datos confirmados para los fallos cubiertos, pero solo mientras las réplicas necesarias y la ruta de aplicación se comporten como se diseñó.

La conmutación por error genera eventos visibles en la aplicación

Los cambios de liderazgo pueden interrumpir transacciones en curso, cerrar conexiones y aumentar la latencia. Las aplicaciones deben distinguir los resultados de base de datos reintentables de los errores de negocio permanentes. Una transacción fallida debe reiniciarse como unidad, en vez de repetir solo su última sentencia.

Los pools de conexiones pueden conservar endpoints inactivos después de un fallo. Las comprobaciones de estado, el comportamiento de DNS, los balanceadores de carga, la validación de certificados y el descubrimiento de topología del driver deben formar parte del plan de pruebas. La base de datos puede estar sana mientras la aplicación sigue sin poder encontrarla.

La capacidad tras un fallo merece un cálculo explícito. Si tres regiones normalmente operan cerca del 70 % de utilización, perder una deja espacio insuficiente para su parte de trabajo. Reservar margen cuesta dinero, pero una topología sin capacidad de conmutación por error no cumple su objetivo declarado.

Los días de simulacro validan el diseño

Los ejercicios de fallo deben desactivar un nodo, aislar una zona, interrumpir la conectividad regional y retirar un endpoint de aplicación. Mide la duración de los errores, la tasa de reintentos de transacción, los percentiles de latencia, el crecimiento de colas y la respuesta del operador.

Ejecuta estos ejercicios después de cambios relevantes en topología, driver o esquema. Un procedimiento probado con el tráfico del año pasado puede fallar tras duplicarse el volumen de datos o cuando un cliente pasa a ser dominante. Automatiza las partes seguras del ejercicio para que la evidencia no dependa de un evento manual anual.

La replicación no es una copia de seguridad

Las réplicas copian fielmente eliminaciones accidentales, migraciones defectuosas y escrituras dañinas de la aplicación. Las copias de seguridad y la recuperación a un punto en el tiempo protegen frente al daño lógico que la replicación no puede detectar.

Los simulacros de restauración deben crear un entorno limpio independiente, verificar checksums o reglas de la aplicación y medir el tiempo total de recuperación. Incluye claves de cifrado, políticas de acceso, versiones de esquema y configuración dependiente. Una copia que existe, pero no puede restaurarse dentro del objetivo, no es un sistema de recuperación adecuado.

Residencia de datos y arquitectura impulsada por el cumplimiento

SQL distribuido puede ubicar grupos de clientes o registros en regiones autorizadas, pero el cumplimiento depende de cada copia, ruta de acceso y proceso operativo. La localidad de la base de datos es un control dentro de un programa más amplio.

Las reglas de residencia necesitan definiciones precisas

Un requisito de que los datos permanezcan en un país puede referirse al almacenamiento, procesamiento, acceso de soporte, copias de seguridad, claves de cifrado o a todo ello. Estas interpretaciones generan topologías distintas. El asesoramiento jurídico y las auditorías deben traducir la regulación y los contratos en controles técnicos verificables.

Los equipos necesitan un inventario de campos regulados y datos derivados. Los registros, trazas, índices de búsqueda, exportaciones analíticas, adjuntos de soporte y colas de mensajes pueden contener la misma información personal que la tabla principal. Restringir la base de datos mientras se exportan payloads sin procesar globalmente no cumple la política prevista.

La minimización de datos puede simplificar el diseño. Si un servicio global solo necesita un identificador de cuenta y un estado agregado, guarda los detalles sensibles en la región autorizada y expón en otros lugares la representación mínima permitida.

Las políticas de ubicación deben incluir las operaciones de ciclo de vida

Las políticas deben indicar dónde pueden existir réplicas activas, réplicas temporales, copias de seguridad, instantáneas, registros de cambios y entornos de restauración. El reequilibrio y el mantenimiento deben respetar el mismo límite. Un procedimiento de emergencia no debería copiar datos regulados a una región no autorizada por comodidad.

El control de acceso necesita límites geográficos y organizativos. Las identidades de servicio deben recibir solo las tablas y operaciones que necesitan. El acceso humano a producción debe registrarse, limitarse en el tiempo cuando sea posible y revisarse. Las claves de cifrado vinculadas a una región pueden añadir control, aunque entonces la disponibilidad de claves y la recuperación ante desastres necesitan su propio diseño.

El traslado de clientes merece un flujo documentado. Cambios de contrato, migraciones de clientes o reestructuraciones corporativas pueden requerir mover registros entre jurisdicciones. El proceso debe identificar cuándo desaparecen las copias antiguas, cómo expiran las copias de seguridad y qué evidencia demuestra que se completó.

Los informes globales pueden necesitar conjuntos de datos derivados

Un panel global puede entrar en conflicto con una ubicación estricta si escanea datos de clientes sin procesar entre regiones. El procesamiento regional puede calcular agregados autorizados localmente y publicar resultados no sensibles en un almacén central de informes.

Las reglas de agregación deben impedir reconstruir registros restringidos. Los grupos pequeños, campos de texto libre y dimensiones detalladas pueden revelar información personal incluso después de quitar identificadores directos. Por tanto, la gobernanza analítica debe formar parte de la revisión de arquitectura, no de un proyecto posterior de informes.

Las cargas operativas y analíticas suelen merecer sistemas separados. La base de datos transaccional protege el estado actual del producto, mientras que pipelines con alcance regional generan conjuntos de datos gobernados para informes. Esta separación mantiene los escaneos analíticos largos lejos de las transacciones sensibles a la latencia.

Planificación de costes y rendimiento

SQL distribuido cuesta más que una base de datos básica de una sola región porque mantiene capacidad redundante y coordina trabajo por una red. La inversión puede justificarse si sustituye costoso trabajo de sharding o evita pérdidas superiores al sobrecoste operativo.

El cálculo y el almacenamiento incluyen el coste de replicación

Un conjunto de datos lógico de 2 TB con tres réplicas completas empieza cerca de 6 TB de datos replicados antes de índices secundarios, espacio temporal de compactación, copias de seguridad y metadatos. La facturación y compresión reales varían por producto, por lo que las estimaciones deben usar almacenamiento físico medido y no solo el tamaño lógico de las tablas.

El cómputo debe cubrir trabajo normal, procesamiento de consenso, reequilibrio, actividad de copias de seguridad y margen ante fallos. Los nodos no son unidades intercambiables de rendimiento cuando una partición está caliente. Añadir capacidad ayuda solo si la carga puede repartirse entre ella.

Los índices multiplican el trabajo de escritura y el almacenamiento. Revisa cada índice secundario según el valor de consulta, la frecuencia de actualización y la ubicación geográfica. Un índice sin usar en un clúster distribuido desperdicia disco y encarece cada escritura afectada.

Los cargos de red pueden ser relevantes

La replicación envía las escrituras entre ubicaciones de réplicas. Las consultas entre regiones, los feeds de cambios, las copias de seguridad y el tráfico de aplicación añaden más transferencias. El tráfico activo en varias regiones puede generar una factura que un benchmark de una sola región nunca revela.

Estima los bytes por transacción, el factor de replicación, la tasa de escritura, la amplificación de índices y la dirección de las transferencias. Después prueba con datos de facturación del proveedor durante una ejecución de carga representativa. El número de solicitudes por sí solo no detecta payloads grandes ni movimiento en segundo plano.

Los errores de localidad elevan tanto el coste como la latencia. Un servicio desplegado en una región puede consultar repetidamente un coordinador en otra debido a la selección de endpoint o a la ubicación del cliente. Las trazas distribuidas y los desgloses de costes regionales pueden revelar ese patrón.

Los recorridos de usuario muestran la latencia acumulada

Modela acciones completas de usuario en lugar de sentencias aisladas. Para checkout, cuenta cada commit secuencial de base de datos, lectura fuerte, llamada a API externa y transferencia a cola. Aplica los tiempos medidos de ida y vuelta regional y los percentiles de ejecución de consultas a la ruta crítica.

Supón que un recorrido contiene dos escrituras de quórum secuenciales, cada una con 90 milisegundos de coordinación de red. Eso aporta unos 180 milisegundos antes del procesamiento de la aplicación. Combinar cambios que comparten una decisión atómica puede eliminar un commit, mientras que paralelizar lecturas independientes puede acortar la ruta.

Las pruebas de carga deben incluir contención y tamaños de payload realistas. Un benchmark con identificadores aleatorios puede distribuirse perfectamente aunque las escrituras de producción se dirijan a unos pocos clientes populares. Incluye cambios de liderazgo y reequilibrios para que la latencia de cola refleje la operación normal del clúster.

Compara la propiedad total con alternativas realistas

La comparación relevante no es SQL distribuido frente a una base de datos imaginaria sin coste operativo. Compárala con una alternativa concreta: PostgreSQL gestionado, réplicas, servicios de sharding, recuperación regional, enrutamiento de aplicación y el personal técnico necesario para mantenerlos.

Incluye trabajo de migración, formación, observabilidad, respuesta a incidentes, planes de soporte y costes de salida. La operación gestionada puede reducir trabajo de infraestructura, mientras que la autogestión puede satisfacer requisitos de control a cambio de un equipo más especializado.

Un modelo financiero simple puede comparar la prima anual de plataforma con la pérdida esperada por caídas, el trabajo de ingeniería retrasado, la exposición de cumplimiento y los ingresos afectados por la latencia regional. Usa rangos para datos inciertos e identifica qué supuesto cambia la decisión. Si el resultado depende de una estimación de caída inverosímilmente alta, probablemente siga siendo adecuada una solución más simple.

Patrones de diseño de esquema y aplicación

Un esquema de SQL distribuido funciona bien cuando sus rutas de acceso reparten el trabajo independiente y mantienen cerca las transacciones relacionadas. Trasladar sin cambios un esquema de un solo nodo puede conservar la corrección, pero producir mala latencia o contención grave.

Las claves primarias influyen en la distribución

Una clave primaria que aumenta continuamente puede dirigir las nuevas filas al final de un range. Los identificadores aleatorios reparten las inserciones, pero una distribución completamente aleatoria puede encarecer los escaneos por cliente o la ubicación regional. Las claves compuestas suelen equilibrar estos objetivos al empezar por un identificador de cliente o cubo y conservar un valor ordenable dentro de ese grupo.

Elige el prefijo según los límites de transacción. Si casi todas las operaciones tienen alcance de cliente, agrupar por cliente puede reducir el trabajo distribuido. Un cliente muy grande puede necesitar cubos dentro de su espacio de nombres para que varias particiones acepten escrituras simultáneamente.

Cambiar una clave primaria después de que una tabla crezca puede requerir una reescritura importante de datos. Prueba diseños candidatos con sesgo realista antes de migrar. Examina el calor de las particiones, la expansión de las transacciones, la localidad de índices y el comportamiento de escaneo, no solo el rendimiento total.

La contención requiere rediseño antes que capacidad

Un contador global, una fila única de configuración o el saldo de un comercio pueden serializar solicitudes que, en otros aspectos, son independientes. Más nodos no pueden eliminar el requisito lógico de que cada transacción actualice el mismo valor.

Sustituye los contadores globales exactos por contadores particionados cuando se acepte agregación temporal. Versiona la configuración en lugar de actualizar una fila a gran frecuencia. Para el estado monetario, conserva la regla contable y busca concurrencia en asientos solo anexables o subcuentas independientes, sin debilitar la corrección.

Las transacciones largas de lectura, modificación y escritura empeoran los conflictos. Lee el conjunto mínimo necesario, evita la interacción de usuario dentro de una transacción y confirma pronto. Si el trabajo de negocio tarda minutos, represéntalo como una máquina de estados compuesta por varias transacciones cortas.

El comportamiento de reintento forma parte del contrato de aplicación

Los drivers pueden reintentar sentencias individuales o exponer un error reintentable al código de aplicación. Entiende qué capa asume la repetición de la transacción completa. Una repetición parcial puede usar decisiones antiguas u omitir lecturas anteriores.

Un bucle de reintento debe tener un máximo de intentos, espera aleatoria e instrumentación. Registra el tipo de conflicto, la operación afectada, el número de intentos y el resultado final. Los reintentos ilimitados convierten la contención en latencia oculta y pueden sobrecargar el clúster.

Las solicitudes de negocio necesitan identificadores estables para poder comprobar con seguridad una respuesta incierta del cliente. Si la base de datos confirma, pero se pierde la respuesta, el cliente debe consultar la operación establecida en vez de enviar una operación semánticamente nueva.

Los cambios de esquema necesitan ensayos a escala de producción

Los cambios de esquema distribuidos pueden actualizar metadatos rápidamente mientras los rellenos de datos y la creación de índices continúan en segundo plano. Esos trabajos consumen almacenamiento, red y CPU, y pueden interferir con las escrituras activas.

Usa migraciones de expansión y contracción. Añade primero campos o tablas compatibles, despliega código que funcione con ambas formas, rellena datos en lotes controlados, cambia las lecturas y elimina la forma antigua después de verificar. La planificación de reversión debe contemplar los datos escritos por la versión nueva.

Prueba migraciones grandes con un volumen y una topología regional similares a producción. Un cambio que termina rápido en un clúster de staging pequeño puede tardar horas en producción y competir con el tráfico de clientes. Monitoriza el progreso, los controles de pausa, el margen de disco y el comportamiento de reintento antes de empezar.

Lista de adopción y prueba de concepto

Una prueba de concepto útil prueba una carga representativa frente a objetivos explícitos de corrección, latencia, resiliencia y coste. Los benchmarks genéricos no pueden determinar si un esquema y una aplicación concretos se comportarán bien.

Selecciona una carga con restricciones reales

Elige un flujo como reservar un recurso escaso, registrar una transferencia contable o aprovisionar un cliente en una región obligatoria. Reutiliza su esquema, consultas, límites de transacción, tamaños de payload y sesgo de tráfico similares a producción.

Define el éxito antes de ejecutar la prueba:

• Resultados correctos con concurrencia y reintentos
• Latencia p50, p95 y p99 por región
• Rendimiento máximo sostenido con margen ante fallos
• Comportamiento de recuperación durante fallos de nodo y región
• Coste medido de cómputo, almacenamiento y red

El margen de seguridad debe provenir del crecimiento previsto y de la capacidad ante fallos, no de un multiplicador arbitrario. Si perder una región está dentro del alcance, las ubicaciones restantes deben manejar la carga redirigida durante la prueba.

Crea una superficie de aplicación realista

Una API y una interfaz pequeña revelan la secuenciación de transacciones, el comportamiento del driver y la latencia percibida por los usuarios que una herramienta solo de base de datos puede pasar por alto. Koder.ai puede crear mediante chat una interfaz React, un backend en Go y una base de PostgreSQL. Su modo de planificación puede ayudar a definir el flujo antes de generar, y la exportación del código fuente permite adaptar la capa de datos a una base de datos candidata.

Usa esa aplicación generada como andamiaje de pruebas, no como prueba de compatibilidad de base de datos. Ejecuta migraciones, inspecciona el SQL generado, configura el driver oficial e implementa deliberadamente los reintentos de transacción. Las instantáneas y la reversión de Koder.ai pueden proteger iteraciones de aplicación, pero no sustituyen las copias de seguridad ni los simulacros de restauración de la base de datos.

Koder.ai también admite despliegue y hosting, lo que permite colocar instancias de la aplicación de prueba cerca de las regiones de base de datos. Así se puede medir la ruta completa de solicitud en vez de emitir todos los benchmarks desde una ubicación. Mantén los datos de prueba sintéticos salvo que el entorno tenga los controles exigidos para registros de producción.

Prueba la operación normal y los fallos

La prueba debe cubrir tráfico estable, picos, particiones calientes, consultas de larga duración, cambios de esquema, trabajo de copias de seguridad y sustitución de nodos. Después interrumpe la conectividad y elimina un dominio de fallo dentro del entorno de prueba autorizado.

Captura abortos de transacción, intentos de reintento, respuestas no disponibles, movimiento de liderazgo, profundidad de cola, uso de disco y transferencia regional. Registra qué tuvo que hacer un operador. Una recuperación automática que requiere un paso manual no documentado aún no está lista para producción.

Restaura una copia de seguridad en un entorno separado y verifica las reglas de la aplicación. Para inventario, confirma que las asignaciones no superan las existencias. Para un libro mayor, recalcula los saldos y verifica que los asientos estén equilibrados. Para la pertenencia SaaS, confirma que las políticas de ubicación y acceso sobrevivieron a la restauración.

Valida la compatibilidad antes de migrar

Inventaría extensiones de base de datos, procedimientos almacenados, triggers, tipos de datos, supuestos de aislamiento, funciones del ORM, consultas de informes, herramientas de copia de seguridad y scripts administrativos. Clasifica cada elemento como compatible, sustituible o bloqueante.

Ejecuta migraciones representativas sobre una copia de tamaño completo o un conjunto de datos generado. Mide la duración de los rellenos, el retraso de captura de cambios de datos, el coste de ejecución dual y el tiempo de cambio. Si la migración usa escrituras duales, define cómo se detectan las discrepancias y qué sistema mantiene la autoridad en cada fase.

Las lecturas en sombra pueden comparar resultados sin cambiar el estado de producción. Ten en cuenta las diferencias de tiempo y las consultas deliberadamente antiguas para que la comparación no marque como corrupción una variación esperada. Cualquier diferencia sin explicación en datos transaccionales necesita resolverse antes del cambio.

Revisa la preparación para producción

Una revisión de producción debe asignar responsables para la operación de la base de datos, los reintentos de aplicación, la seguridad, la política de residencia, los costes y la respuesta a incidentes. Debe incluir paneles, alertas, runbooks, umbrales de capacidad, evidencia de restauración y un punto de decisión para revertir.

La decisión final aún puede ser seguir con PostgreSQL o MySQL. Una prueba de concepto tiene éxito cuando produce evidencia fiable, aunque esa evidencia muestre que la opción distribuida cuesta más de lo que justifican los requisitos actuales. Cuando los requisitos sí respalden la adopción, migra gradualmente, mide cada etapa y conserva una ruta de vuelta probada hasta que el nuevo sistema se haya demostrado con carga real.