AWS terminó el soporte para Amazon Quantum Ledger Database el 31 de julio de 2025. No hubo keynote, ni blog, ni anuncio público — los clientes existentes se enteraron de un correo rutinario y una página de documentación actualizada. Para los equipos que habían construido flujos de cumplimiento sobre QLDB, el aviso marcó el inicio de una ventana de migración que se cerró más rápido de lo que la mayoría esperaba. Este artículo es para los compradores que ahora evalúan reemplazos — y para cualquiera que quiera que su migración actual sea la última que tenga que hacer.
Por qué la recomendación de AWS no es del todo una respuesta
AWS recomienda oficialmente migrar cargas de QLDB a Amazon Aurora PostgreSQL, que ofrece capacidades tipo ledger mediante extensiones (ver aws.amazon.com/qldb/faqs). Aurora provee logging de auditoría detallado y retención permanente de logs. No provee verificabilidad criptográfica. Eso importa — la cadena de hash criptográfica era la razón por la que muchos equipos eligieron QLDB originalmente.
La consecuencia práctica es que los logs de auditoría basados en Aurora pueden ser modificados por un administrador privilegiado. La historia existe; la evidencia de manipulación no. La propia guía de migración de Microsoft para clientes de QLDB (techcommunity.microsoft.com, moving from QLDB to Azure SQL Ledger) anota la misma brecha y posiciona el Ledger a nivel de base de datos de Azure SQL Ledger como respuesta parcial — pero con la misma forma de un solo vendor que la caída de QLDB expuso.
Los criterios de reemplazo
La lección de QLDB no es que los ledgers en la nube sean malos. Es que la inmutabilidad gestionada por proveedor tiene un modo de falla por decisión de negocio. Cualquier reemplazo debe ser evaluado contra tres criterios antes de reconstruir tu pipeline de integridad por segunda vez:
- ✓¿Puedes verificar sin el vendor? Las pruebas de QLDB requerían acceso a la API de AWS. Si el endpoint del servicio del vendor desaparece, las pruebas desaparecen con él. Los anclajes de Certyo son verificables contra Polygon directamente, con o sin cooperación de Certyo.
- ✓¿El ancla de confianza es neutral a la nube? Un ledger cuyo root-of-trust es un solo operador de nube hereda el roadmap de negocio de ese operador. Las blockchains públicas y el storage direccionado por contenido no comparten ese modo de falla.
- ✓¿Los artefactos de prueba son portables? Si tu auditor o contraparte no puede verificar independientemente un paquete de prueba sin acceso a tu cuenta del vendor, la prueba es una promesa, no evidencia.
Los cuatro reemplazos realistas
El conjunto práctico de reemplazos es pequeño. Cada uno tiene un perfil:
Aurora PostgreSQL te da logs de auditoría, no prueba criptográfica. Azure SQL Ledger te da integridad a nivel de base de datos pero hereda el riesgo de un solo vendor. Azure Confidential Ledger agrega aislamiento TEE pero sigue corriendo en una sola nube. Certyo ancla a Polygon y publica pruebas que funcionan sin nosotros. Ninguna de las cuatro es perfecta; tres de ellas son versiones de la apuesta QLDB.
Por qué "nativo a la nube" fue el error original
La frase "ledger nativo a la nube" sonaba sofisticada en 2019. En retrospectiva, nombraba el bug: un ledger que depende de la nube es solo tan permanente como el roadmap del vendor de la nube. Los ledgers se supone que sobreviven a sus operadores. Un ledger que muere cuando su vendor cierra el producto no es realmente un ledger — es una base de datos con garantías de retención.
La jugada honesta es tratar esta migración como la que hace innecesaria la siguiente. Elige un reemplazo cuyos artefactos de prueba sobrevivan al reemplazo mismo. Eso acota el campo rápidamente.
A quién le pega más fuerte esta lección
Tres grupos necesitan tomar la siguiente decisión deliberadamente:
- ●Ex-clientes de QLDB a mitad de migración — Ya perdiste la verificabilidad criptográfica si migraste a Aurora. Si el alcance de cumplimiento aún lo requiere, estás corriendo con tiempo prestado sobre una solución interina.
- ●Equipos evaluando ACL o Azure SQL Ledger — Ambos están vivos y ambos funcionan. Ambos heredan el riesgo de un solo vendor. Si ese es un trade aceptable para tu organización, bien — pero que sea una decisión consciente, no un default.
- ●Compras y finanzas — En términos de presupuesto, una segunda migración dentro de tres a cinco años es el modo de falla a prevenir. El delta por año entre un reemplazo con lock-in y uno neutral a la nube es pequeño; el delta en exposición al riesgo de migración es grande.
Qué cambia esta vez y fuentes
Lo que hace diferente al mercado post-QLDB es que las alternativas ahora existen. El anclaje en cadena pública maduró. La economía de lotes hace los costos por-registro negligibles. El direccionamiento por contenido IPFS está listo para producción. Ninguna de estas era obviamente grado-producción en 2019; ahora sí. El caso honesto para un reemplazo neutral a la nube es que la migración de 2025 es evitable hacia adelante. Fuentes: InfoQ — infoq.com/news/2024/07/aws-kill-qldb, AWS FAQ — aws.amazon.com/qldb/faqs, guía de migración Microsoft — techcommunity.microsoft.com/blog/azuresqlblog/moving-from-amazon-quantum-ledger-database-qldb-to-ledger-in-azure-sql/4246237, alternativas DoltHub — dolthub.com/blog/2024-08-12-qldb-deprecated-alternatives. Ver también nuestra página /es/compare/aws-qldb para una comparación directa con Certyo.
Un ledger que muere cuando su vendor cierra el producto no es un ledger. Es una base de datos con garantías de retención. Elige el reemplazo que sobreviva al siguiente cierre.