La estrategia multicloud de Oracle se acelera: implicaciones industriales de la interconexión entre nubes GA, la base de datos Exascale y la expansión regional

La estrategia multicloud de Oracle se acelera: implicaciones sectoriales de la interconexión entre nubes GA, las bases de datos Exascale y la expansión regional

Introducción

Entre mayo y agosto de 2026, Oracle dio a conocer de forma consecutiva una serie de avances en su blog oficial de multicloud: Oracle Interconnect for AWS pasó de disponibilidad limitada a disponibilidad general (GA), Oracle AI Database@AWS y Oracle AI Database@Google Cloud incorporaron, respectivamente, infraestructura Exascale y capacidades de almacenamiento Exadata Exascale, al tiempo que la cobertura regional se amplió a 22 en todo el mundo. Aunque estas actualizaciones parecen dispersas, apuntan en realidad a una misma cuestión: cuando las cargas de trabajo empresariales están distribuidas de forma natural entre varias nubes, ¿pueden los activos de bases de datos, considerados los más difíciles de migrar, ejecutarse entre nubes sin reestructurar las aplicaciones? Para los CTO y los arquitectos de nube, esto está directamente relacionado con la estructura de costos de las redes entre nubes, los modelos de despliegue de bases de datos y las vías para lograr la residencia de datos y la continuidad del negocio.

1. Antecedentes del evento: una serie de avances concentrados durante tres meses

La idea central de la estrategia multicloud de Oracle no es complicada: ejecutar los servicios de Oracle Database en infraestructura de OCI desplegada cerca de las regiones de otras nubes y entregarlos a los clientes mediante una cadena de herramientas conocida y facturación consolidada. Este conjunto de anuncios del verano de 2026 representa una expansión simultánea de esta idea en dos dimensiones: capacidades y geografía.| Fecha | Evento | Puntos clave | | --- | --- | --- | | 15 de mayo | Disponibilidad limitada de Oracle Interconnect for AWS | Anunciado por Nathan Thomas, vicepresidente sénior de gestión de productos de OCI; el objetivo es reemplazar las redes entre nubes creadas por los clientes con conexiones gestionadas | | 20 de mayo | OCI GoldenGate GA en Oracle AI Database@Google Cloud | Se puede aprovisionar directamente desde la consola de Google Cloud y pagar mediante descuentos por compromiso de uso de Google Cloud | | 20 de mayo | Oracle AI Database@AWS llega a São Paulo | Cubre el mercado de Sudamérica, con una zona de disponibilidad inicial | | 17 de junio | Primer aniversario del lanzamiento de Oracle AI Database@AWS | Anunció la disponibilidad general (GA) de Autonomous AI Database Serverless, la próxima disponibilidad de la infraestructura Exascale, la expansión a 20 regiones de AWS, el nivel MAA Platinum y un Acuerdo de Colaboración Estratégica (SCA) a largo plazo | | 23 de junio | Se añaden Estocolmo y San José | El número total de regiones globales alcanza las 22 | | 29 de julio | Disponibilidad general de Oracle Interconnect for AWS | Primer despliegue en OCI Ashburn y AWS Este de EE. UU. (Virginia del Norte); más pares de regiones se lanzarán posteriormente | | 12 de agosto | ExaDB-XS disponible en Oracle AI Database@AWS | Se factura por ECPU y uso de almacenamiento, reduce el costo de entrada y se comercializa a través de AWS Marketplace | | 14 de agosto | Exadata Exascale llega a Oracle AI Database@Google Cloud | Los clientes pueden aprovisionar clústeres de VM de Exadata con almacenamiento Exascale |

Cabe destacar que los anuncios de esta ronda se concentran en AWS y Google Cloud. Este ritmo de establecer primero vínculos profundos con algunos hiperescaladores indica que la estrategia multinube de Oracle se acerca más a la replicación de capacidades que a una expansión generalizada.

2. Análisis técnico: qué problema resuelve cada una de las tres cosas

1. Interconexión entre nubes: convertir la red de un proyecto en un servicioEn la etapa temprana del multicloud, había principalmente dos formas de conectar dos nubes: hacer que el tráfico circulara por la red pública o construir un túnel cifrado propio. La primera presentaba una superficie de exposición evidente en seguridad, disponibilidad y capacidad; la segunda, aunque dejaba fuera la red pública, trasladaba toda la carga de adquisición, configuración y gestión de capacidad al cliente. En la práctica, las empresas también debían coordinar simultáneamente dos modelos de enrutamiento que no estaban diseñados el uno para el otro, gestionar contratos con terceros en ambos lados y montar una red propia antes de empezar realmente el negocio.

Oracle Interconnect for AWS pretende cambiar precisamente esta capa. Ofrece una conexión privada, de alta velocidad y totalmente gestionada entre OCI y AWS, utiliza cifrado IEEE 802.1AE MACsec de forma predeterminada, aplica la tarificación de conexión unificada y globalmente coherente de OCI, no cobra tarifas por transferencia de datos y cuenta con el soporte conjunto de Oracle y AWS. En términos no técnicos: equivale a construir una autopista dedicada entre dos campus, operada conjuntamente por ambas partes, de modo que la empresa ya no necesita pavimentar el camino, comprar el terreno ni mantener la calzada.

2. Exascale: desacoplar cómputo y almacenamiento, reducir la barrera de entrada a Exadata

La Exadata tradicional se parecía más a un dispositivo integrado: el cómputo y el almacenamiento se escalaban juntos según una proporción fija, y cualquier desviación en la planificación de capacidad provocaba desperdicio o limitaciones. El cambio clave de Exascale es separar ambos.

En el lado de AWS, ExaDB-XS se basa en el modelo de nube elástica multiinquilino de Oracle; los clientes pueden empezar con clústeres de VM de pequeña escala, escalar el cómputo y el almacenamiento de forma independiente, y pagar solo por los ECPU y el almacenamiento que realmente utilicen. También admite Oracle Database 19c y Oracle AI Database 26ai, y ofrece thin clone, así como capacidades de instantáneas y clonación basadas en redirect-on-write. En el lado de Google Cloud, los clientes pueden aprovisionar clústeres de VM de Exadata con almacenamiento Exascale, escalar el almacenamiento de forma flexible a medida que crecen las necesidades de la base de datos y, al mismo tiempo, conservar las características de rendimiento, disponibilidad y fiabilidad de la Exadata dedicada.

Para los responsables de gestión, el fondo de este cambio es una transformación de la lógica de compra: pasar de adquirir toda la capacidad de una vez a pagar según el uso y escalar conforme al crecimiento, con lo que el carácter de gasto de capital se desplaza cada vez más hacia el gasto operativo.

3. OCI GoldenGate: el plano de datos en escenarios multicloudEjecutar bases de datos entre nubes hace imposible evitar la sincronización de datos. Una vez que OCI GoldenGate está disponible de forma general en Google Cloud, los clientes pueden activar este servicio gestionado directamente desde la consola de Google Cloud y pagar mediante los compromisos de Google Cloud. Ofrece captura de datos modificados (CDC) de baja latencia y replicación en tiempo real, lo que respalda migraciones de bases de datos de bajo riesgo, arquitecturas híbridas y multinube, mejoras de disponibilidad y análisis casi en tiempo real entre fuentes de datos Oracle y no Oracle.

CDC puede entenderse como un registro continuo y actualizado de cambios: cada modificación de datos en la base de datos de origen se captura y se sincroniza con el destino, en lugar de esperar a que una ventana de procesamiento por lotes los traslade en bloque. Esto permite que las cargas de trabajo de operaciones, análisis e IA se basen en datos sincronizados de forma continua.

III. Análisis de impacto empresarial

Estructura de costos. ExaDB-XS se factura por ECPU y uso de almacenamiento, lo que reduce directamente la barrera de prueba y de entrada a Exadata; el escalado independiente de Exascale reduce el desperdicio de reservar capacidad para picos. Interconnect utiliza precios de conexión unificados y no cobra por transferencia de datos, lo que hace que el gasto de red multinube se acerque más a un elemento fijo predecible. Cabe señalar que el costo total multinube aún debe calcularse de forma integral combinando las reglas de facturación de ambos extremos; la red es solo una parte.

Modelo de implementación. Para los clientes de Oracle que ya ejecutan aplicaciones en AWS, no rehacer la arquitectura es la propuesta de valor central de esta actualización: los servicios de base de datos se ejecutan sobre infraestructura de OCI, pero se despliegan cerca de las aplicaciones en AWS. La migración por fases, las arquitecturas de aplicaciones distribuidas y la reducción de la dependencia de la internet pública son escenarios directamente implementables.

Operaciones y soporte. La facturación consolidada, el uso continuado de las cadenas de herramientas existentes y las interfaces de soporte coordinado de Oracle y AWS reducen la fricción organizativa de los equipos multinube. Pero la complejidad de las operaciones multinube no desaparece por ello; solo se traslada de la red autogestionada y la gestión de contratos a la identidad federada, la supervisión y la localización de fallos.

Seguridad y cumplimiento. El cifrado MACsec predeterminado y los enlaces privados reducen la superficie de exposición a la internet pública. La expansión regional es una respuesta directa a los temas de cumplimiento: Estocolmo atiende las necesidades de residencia de datos de los mercados nórdico y europeo, San José se sitúa cerca de los clústeres tecnológicos y empresariales del oeste de Estados Unidos, y São Paulo cubre el mercado sudamericano. Para los sectores regulados, este tipo de elección de región suele tener más peso en la decisión que los indicadores de rendimiento.

IV. Análisis de la competencia en el mercadoDesde la perspectiva del panorama competitivo, la mayor particularidad de esta tanda de actualizaciones es la competencia en segmentos diferenciados. Oracle no compite frontalmente por capacidad de cómputo genérica con los hiperescaladores en la capa de IaaS, sino que trata la base de datos como un producto entregado de forma multicloud, permitiendo que AWS y Google Cloud obtengan más cargas de trabajo, mientras Oracle captura el consumo de base de datos. Esto se parece más a una alianza complementaria: el acuerdo de colaboración estratégica a largo plazo (SCA, por sus siglas en inglés) anunciado por ambas partes el 17 de junio consolidó aún más esta relación. Según la información oficial, un año después del lanzamiento de Oracle AI Database@AWS, cientos de clientes ya ejecutan cargas de trabajo críticas de negocio sobre él.

Entre los posibles beneficiados se incluyen: clientes empresariales que poseen numerosos activos de bases de datos Oracle, pero desean mantener sus aplicaciones en otras nubes; AWS y Google Cloud, porque albergan más cargas de trabajo de bases de datos empresariales y de IA; así como los canales e integradores que operan en torno a AWS Marketplace y a los compromisos de gasto de Google Cloud.

Entre los posibles afectados se incluyen: los proveedores de servicios de terceros cuya actividad principal son las líneas dedicadas multicloud propias y el alojamiento de red, cuya propuesta de valor se diluye con la conectividad gestionada y la tarificación unificada; y la narrativa de que las bases de datos de negocio deben reescribirse por completo como bases de datos nativas de la nube: el soporte de Exascale y de las dos versiones, 19c/26ai, permite a más empresas elegir una ruta gradual de primero migrar y después modernizar. En consecuencia, la resistencia a la sustitución que enfrentan los proveedores de bases de datos nativas de la nube al intentar captar cargas de trabajo existentes de Oracle también aumentará.

V. Observación de tendencias del sector

El foco de competencia multicloud está pasando de la conectividad al plano de datos. En los últimos años, el problema de ingeniería del multicloud era principalmente la interconexión de redes; mientras que capacidades como Exascale, GoldenGate y la búsqueda vectorial nativa de IA indican que la competencia de la siguiente etapa se dará en cómo fluyen los datos entre nubes y cómo los usa la IA.

La dirección de la gravedad de los datos se invierte. La práctica tradicional era llevar las aplicaciones junto a los datos; ahora, en cambio, se llevan los servicios de bases de datos junto a las aplicaciones: la base de datos se ejecuta sobre la infraestructura de OCI, pero se despliega cerca de las regiones de AWS o Google Cloud. Este modelo de nube dentro de la nube podría convertirse en la ruta de migración predeterminada para los sistemas heredados empresariales.

La soberanía y la regionalización se convierten en características del producto. La llegada sucesiva a Estocolmo, São Paulo y San José demuestra que la cobertura regional ya no es solo una optimización de latencia, sino una infraestructura de cumplimiento para la residencia de datos y la continuidad del negocio.

La frontera entre la IA y las bases de datos sigue difuminándose. Desde la denominación de los productos hasta la combinación de capacidades (Autonomous AI Lakehouse, búsqueda vectorial nativa de IA, versión 26ai), Oracle está integrando capacidades de IA en la capa de base de datos, en lugar de hacer que las empresas construyan por separado, fuera de la base de datos, un conjunto de búsqueda vectorial y plataforma de características.Estos cambios apuntan en conjunto a una conclusión: la multinube está pasando de ser una elección de arquitectura de red a una elección de arquitectura de datos, y la competencia en infraestructura de nube de los próximos cinco años girará más en torno a la portabilidad de los servicios de datos.

CloudTechDaily Insight

Lo más digno de registrar de esta tanda de anuncios no es una función concreta, sino que está cambiando la unidad de tarificación de la competencia multinube. Antes, cuando las empresas evaluaban la multinube, miraban el ancho de banda de las líneas dedicadas, el tráfico de salida y el personal de operaciones; ahora lo que se pone sobre la mesa es el costo de entrada de la base de datos (facturado por ECPU y almacenamiento), la forma de tarificar la conectividad entre nubes (precio de conexión unificado, sin cargos por transferencia de datos) y si los datos pueden ser consumidos por IA in situ. Cuando estos elementos se productizan, la decisión multinube deja de ser una cuestión de viabilidad técnica y se convierte en un problema calculable en términos financieros y de cumplimiento.

Para la estrategia de TI de las empresas, hay tres puntos que merecen incluirse en la evaluación. Primero, las bases de datos entre nubes ya no son el punto final de un proyecto de migración, sino que pueden convertirse en un estado operativo de largo plazo, por lo que los criterios de revisión de arquitectura deben ajustarse en consecuencia. Segundo, una vez que la capa de conectividad se gestiona como servicio, mejora la previsibilidad de los costos entre nubes, pero la dependencia también se profundiza: los clientes deben evaluar cuánto dependen de la relación de colaboración de largo plazo entre ambos proveedores y de los procesos de soporte conjunto. Tercero, la expansión regional aporta opciones de cumplimiento, no solo beneficios de rendimiento; las industrias reguladas deberían incorporar la lista de regiones a la planificación de residencia de datos y continuidad.

Hay que reconocer que este modelo aún depende de la voluntad de colaboración y la hoja de ruta de productos de los hiperescaladores. La información revelada en esta ronda se centra en AWS y Google Cloud, por lo que la cobertura aún es incompleta; el desempeño real del soporte conjunto en la localización de fallos y la delimitación de responsabilidades también necesita más validación en entornos de producción. Por ello, un enfoque más pragmático es: validar con clústeres de pequeña escala de ExaDB-XS el rendimiento y la experiencia operativa de bases de datos críticas para el negocio en entornos multinube, sustituir las redes públicas entre nubes o los enlaces propios existentes con un piloto de Interconnect, y completar una doble verificación del modelo de costos y la residencia de datos antes de ampliar la escala.

A medio y largo plazo, es probable que la base de datos como servicio multinube pase de ser una excepción a convertirse en la configuración predeterminada del sector, tal como ocurrió en su momento con las bases de datos gestionadas. Una vez que los principales proveedores de bases de datos den este paso, la presión para que otras empresas y proveedores de nube sigan su ejemplo se hará evidente rápidamente; este es el impacto más profundo de este acontecimiento en la industria de la computación en la nube.

---

Fuente de referencia: blog oficial de Oracle, «Oracle Multicloud – What's News», https://blogs.oracle.com/cloud-infrastructure/oracle-multicloud-whats-new-blog