Users can now provision a DB system with an IPv6 address when the selected subnet supports IPv6. Applications can then reach the DB system through its IPv6 primary endpoint.

IPv6 connectivity, familiar MySQL

Modern cloud applications increasingly use IPv6 to expand address capacity, simplify large network estates, and support long-term infrastructure modernization. Yet a single IPv4-only tier can keep an otherwise IPv6-ready architecture dependent on private IPv4 addressing and separate routing patterns.

MySQL HeatWave on Oracle Cloud Infrastructure (OCI) now removes that constraint for the database connection path. You can create a DB system with an IPv6 address in an IPv6-enabled subnet, allowing client applications with network reachability to connect to the DB system’s primary endpoint over IPv6.

For developers, the key point is simple: IPv6 support changes how the application reaches MySQL HeatWave. It does not change SQL semantics, schemas, transactions, authentication, connectors, or HeatWave query processing.

An IPv6 application path to the MySQL HeatWave DB System

What this enables

  •  Cloud-native applications. Compute instances, containers, Kubernetes workloads, and microservices in an IPv6-enabled network can use the standard MySQL protocol over an IPv6 path.
  •  More address space. Large enterprises can reduce the need to allocate additional RFC 1918 space solely for new database connectivity, especially where private IPv4 ranges are already crowded or overlap across acquired and hybrid environments.
  •  Cleaner modernization. An IPv6-ready application stack no longer needs to retain an IPv4-only database path simply because the managed database endpoint requires IPv4.
  •  Long-term flexibility. Network teams can move application tiers toward IPv6 while developers keep the same MySQL clients, connection behavior, and SQL. DNS names can further decouple application configuration from literal addresses.
Simplified IPv6-ready application deployment

MySQL already understands IPv6

This announcement is about the managed-service endpoint, not first-time IPv6 support in MySQL Server. MySQL Server can accept TCP/IP connections from clients over IPv6, account host specifications can use IPv6 addresses, and MySQL provides IPv6-aware address functions such as INET6_ATON() and INET6_NTOA().

The new MySQL HeatWave capability brings IPv6 to the OCI service networking layer by allowing the DB system’s primary endpoint to be provisioned with an IPv6 address. After the connection is established, the application uses MySQL in the usual way.

How to enable IPv6 when provisioning the DB system

The following workflow applies when you create a DB system, clone a DB system, or restore to a new DB system.

1. Prepare an IPv6-enabled VCN and subnet

Select an OCI VCN and subnet that support IPv6. Confirm that the application-to-database route, Network Security Groups (NSGs), security lists, firewalls, and enterprise network controls permit the required IPv6 traffic. IPv6 addressing does not bypass any of these controls or MySQL authentication.

2. Configure the required policy

In addition to the normal permissions used to create a MySQL HeatWave DB system and attach it to a subnet, Oracle documents the following resource-principal policy for DB systems that use IPv6. Replace the placeholders with your compartment values and review the policy with your tenancy administrator.

Allow any-user to {IPV6_READ, IPV6_CREATE, IPV6_UPDATE, IPV6_DELETE,
VNIC_UNASSIGN, VNIC_ASSIGN, SUBNET_ATTACH} in compartment
<subnet_compartment_name> where all {request.principal.type='mysqldbsystem',
request.resource.compartment.id='<DBsystem_compartment_OCID>'}

3. Enable IPv6 on the primary endpoint

In the OCI Console, open the DB system provisioning panel and expand:

Advanced Options -> Connections -> Primary endpoint

Select Enable IPv6. You can let Oracle automatically assign an available IPv6 address from the subnet or specify an IPv6 subnet prefix or IPv6 address.

Connect without changing application logic

Once the DB system is active and the application host has IPv6 reachability, connect with the same MySQL client or driver you already use. In production, a DNS hostname is generally preferable to embedding a literal address because it keeps application configuration independent of the underlying address.

mysql -h mysql-db.example.internal -u appuser -p

A Python application remains equally familiar:

import mysql.connector

connection = mysql.connector.connect(
    host="mysql-db.example.internal",
    user="appuser",
    password="...",
    database="orders",
)

The host must resolve and route to the IPv6 primary endpoint from the client environment. Your connector, operating system, and DNS path must also support IPv6. No application SQL changes are required.

Verify the path

  1. From the application host, confirm that the endpoint hostname resolves to the expected IPv6 address using your operating system’s DNS tools.
  2. Verify routing, NSG or security-list rules, firewall rules, and TCP access to the configured MySQL port.
  3. Connect with MySQL Client, MySQL Shell, or the application connector and run a basic query.

If the application stores or validates IP addresses, MySQL’s native functions can convert IPv4 or IPv6 strings to a compact binary value and back.

SELECT HEX(INET6_ATON('2001:db8::10'));
SELECT INET6_NTOA(INET6_ATON('2001:db8::10'));

Things to consider before enabling IPv6

The following should be taken into consideration before enabling IPv6 on the DB system. Recheck the documentation before production deployment.

  •  The selected subnet must support IPv6.
  •  The documented IPv6 resource-principal permissions must be in place in the subnet compartment.
  •  DB systems with IPv6 addresses currently do not support read endpoints, read replicas, REST endpoints, or MySQL Studio.
  •  IPv6 does not replace routing, NSGs, security lists, firewalls, TLS, or MySQL authentication controls.

A workload that depends on read scaling, MySQL REST Service, or MySQL Studio should evaluate the current restrictions before choosing an IPv6-enabled DB system.

Modernize the network, not the programming model

The practical value of IPv6 support is what developers do not have to redesign. Applications still connect with standard MySQL protocols and connectors, authenticate with MySQL accounts, issue the same SQL, and use the same schemas and transactions. The change is the network path to the managed DB system primary endpoint.

For architects, that means MySQL HeatWave can participate more naturally in IPv6-enabled OCI and enterprise network designs. For developers, it means the database tier no longer must remain an IPv4-only exception in an otherwise modern application stack.

Learn more

See the following for more information:

1. HeatWave: IPv6 Support release note – Release date and announcement that a DB system can be created with an IPv6 address.

2. Advanced Options – Connections – Enable IPv6 workflow, automatic or specified address selection, optional hostname, and current exclusions.

3. DB System Endpoints – Primary endpoint behavior and restrictions for DB systems with IPv6.

4. Mandatory Policies and Permissions – Documented resource-principal policy for IPv6-enabled DB systems.

5. API Operations – Permissions required for CreateDbSystem when IPv6 is enabled.

6. MySQL 8.4 Reference Manual – IPv6 Support – MySQL Server IPv6 connections, account hosts, and address-function overview.

7. MySQL 8.4 Reference Manual – Miscellaneous Functions – INET6_ATON(), INET6_NTOA(), and binary representation details.