Amazon Web Services ha detallado por primera vez en un paper académico el funcionamiento interno de Aurora DSQL, su base de datos SQL sin servidor con capacidades activas-activas multirregión. El artículo, publicado en arXiv el 14 de julio de 2026 por Marc Brooker —ingeniero de AWS— y revisado dos días después, describe una arquitectura radicalmente disgregada que, según el análisis del blog técnico Murat Buffalo (escrito por un exintegrante del equipo), está construida sobre "apuestas de ingeniería agresivas y muy opinionadas" que redefinen varios dogmas de los sistemas distribuidos clásicos.
La idea central, resume Murat, es sencilla: "Tomamos una base de datos monolítica tradicional y explosionamos cada uno de sus componentes en un servicio independiente y escalable horizontalmente". Aurora DSQL divide el sistema en cinco bloques especializados: los Query Processors (QP), máquinas virtuales sin estado que ejecutan un motor PostgreSQL personalizado; los Storage Nodes, fragmentos que almacenan los datos y sirven lecturas históricas mediante MVCC; los Adjudicators, la capa que decide si una transacción es segura de confirmar; los Journals, un log de replicación de alta disponibilidad; y los Crossbars, la capa de enrutamiento que conecta Journals con Storage Nodes.
Una de las decisiones más llamativas es lo que Murat denomina "la apuesta del reloj sincronizado": para conseguir lecturas sin coordinación entre regiones, DSQL depende exclusivamente de los relojes físicos de alta precisión de AWS TimeSync. Cada Query Processor consulta su reloj local y pide al almacenamiento los datos correspondientes a ese microsegundo exacto, eliminando la necesidad de consenso durante las lecturas.
En el lado de las escrituras, el sistema rechaza el bloqueo pesimista y adopta Control de Concurrencia Optimista (OCC) combinado con Snapshot Isolation mediante MVCC. Como los lectores trabajan sobre una instantánea del pasado, los conflictos lectura-escritura son imposibles. Para los write-skews —anomalías típicas bajo snapshot isolation—, el paper recomienda a los desarrolladores el uso explícito de cláusulas FOR UPDATE y diseñar esquemas que fuercen conflictos escritura-escritura que reflejen las reglas de negocio. AWS también impone guardrails duros: las transacciones están limitadas a 3.000 filas y 10 MiB, una decisión justificada con la Ley de Little para garantizar una latencia de cola estable y predecible.
El paper sostiene además que "la consistencia eventual está muerta". DSQL ofrece linearizabilidad para operaciones sobre objetos individuales y snapshot isolation consistente para transacciones multi-objeto, argumentando que los desarrolladores difícilmente pueden escribir lógica de negocio correcta sobre sistemas eventualmente consistentes. Para los commits multirregión, el equipo implementa un truco inspirado en el protocolo Warp: los Adjudicators votan, pero solo el líder escribe la confirmación final en un único Journal, evitando coordinar múltiples logs y sorteando el problema de las dos RTT del Two-Phase Commit tradicional sobre redes de área amplia.
El resultado, según el documento, es un sistema capaz de escalar elásticamente desde cero hasta millones de transacciones por segundo, con transacciones ACID, consistencia fuerte y disponibilidad continua ante fallos de zonas e incluso regiones completas, minimizando la latencia cruzada al requerir coordinación únicamente en el momento del commit, no en cada sentencia.
La publicación tiene un valor simbólico importante: es la primera vez que AWS describe con detalle técnico la arquitectura de un servicio que ya está disponible comercialmente y que supone un punto de inflexión frente a diseños tradicionales como Google Spanner —que también usa relojes sincronizados, pero apostando por transacciones síncronas— o CockroachDB —que replica el modelo de Spanner con consenso explícito. Aurora DSQL lleva el enfoque asíncrono-coordinado-solo-en-commit mucho más lejos, aunque a costa de imponer límites rígidos al tamaño de las transacciones. La siguiente prueba de fuego será observar cómo responde la comunidad ante estos compromisos y si el modelo "disgregado y optimista" se consolida como referencia para la próxima generación de bases de datos cloud-native.