MySQL HeatWave on STACKIT: MariaDB and the choices around it

A MySQL DB system, assessed

A small estate written for this page: a VCN, a private database subnet and a highly available MySQL DB system. StackToIT assessed it on 4 November 2026. Left: the DB system as written, lines 35 to 55 of main.tf. Right: the decision the run recorded, an excerpt of assessment.json with the values as written. assessment.json is written as a single line, so the pane shows selected fields of each unit, indented and nested as in the file, with the values unchanged.

resource "oci_mysql_mysql_db_system" "shop" {
  compartment_id      = var.compartment_id
  availability_domain = var.availability_domain
  display_name        = "shop-mysql"
  shape_name          = "MySQL.4"
  subnet_id           = oci_core_subnet.db.id
  admin_username      = "dbadmin"
  admin_password      = var.mysql_admin_password
  data_storage_size_in_gb = 100
  is_highly_available = true
  mysql_version       = "8.4.3"

  backup_policy {
    is_enabled        = true
    retention_in_days = 14
  }

  maintenance {
    window_start_time = "SUN 03:00"
  }
}

[
  {
    "id": "oci_mysql_mysql_db_system.shop",
    "result": {
      "class": "REPLATFORM",
      "confidence": "MEDIUM",
      "target": {
        "service": "STACKIT MariaDB"
      },
      "reason": "STACKIT offers MariaDB, not MySQL; test MySQL-specific features and any HeatWave analytics before cut-over, and move the data with a logical dump."
    }
  }
]

• Replatform, medium confidence

  The class is REPLATFORM with MEDIUM confidence. The target is STACKIT MariaDB, which the architect report lists as generally available and offered in the regions eu01 and eu02.

• The reason is a test plan

  The run says STACKIT offers MariaDB, not MySQL, and asks you to test MySQL-specific features and any HeatWave analytics before cut-over.

• Network units come first

  The VCN is in wave 1, the database subnet in wave 2 and the DB system in wave 3, because it depends on the subnet.

Options for the database

Option 1 is what the run assesses. Options 2 and 3 are design alternatives that sit outside the run, and option 4 is the decision the run's reason asks you to test; they are listed so the decision is made on purpose.

The demo estate declares the DB system only; a HeatWave cluster would be a further resource of its own, and this run does not include one.

How to decide

Four questions separate the options. Answer them in this order.

• Which MySQL features do you use?

  List what the application relies on beyond plain SQL: stored routines, JSON columns, authentication plugins, replication settings. STACKIT describes MariaDB as a drop-in replacement for MySQL; the run still asks for a test, and so should you.

• Which MariaDB version?

  As of November 2026, the STACKIT page marks version 10.6 as deprecated, with decommissioning scheduled for 1 July 2027, and asks users to be on 10.11 or newer. Land on a current version so the first upgrade is not a forced one.

• Who operates the engine?

  If the answer is a platform team that does not want to patch databases, option 1 is the fit. If the answer is a team that needs the exact MySQL engine, option 2 buys that at the price of running it.

• What happens to analytics?

  If nobody uses a HeatWave cluster, there is nothing to decide. If someone does, the queries are the unit of work, not the cluster.

The settings the run leaves to you

The DB system is not drafted. The run lists 13 critical settings of the unit for your team; the left pane shows the attribute field of each entry, in the order of assessment.json. The data movement file records that no mechanism is chosen. assessment.json is written as a single line, so the pane shows selected fields of each unit, indented and nested as in the file, with the values unchanged.

{
  "id": "oci_mysql_mysql_db_system.shop",
  "property_accounting": {
    "critical": [
      {
        "attribute": "admin_password"
      },
      {
        "attribute": "admin_username"
      },
      {
        "attribute": "availability_domain"
      },
      {
        "attribute": "backup_policy.is_enabled"
      },
      {
        "attribute": "backup_policy.retention_in_days"
      },
      {
        "attribute": "compartment_id"
      },
      {
        "attribute": "data_storage_size_in_gb"
      },
      {
        "attribute": "display_name"
      },
      {
        "attribute": "is_highly_available"
      },
      {
        "attribute": "maintenance.window_start_time"
      },
      {
        "attribute": "mysql_version"
      },
      {
        "attribute": "shape_name"
      },
      {
        "attribute": "subnet_id"
      }
    ]
  }
}

| Unit | Source service | Target service | Application | Mechanism | State | Data class | RPO | Downtime tolerance |
|---|---|---|---|---|---|---|---|---|
| oci_mysql_mysql_db_system.shop | oci_mysql_mysql_db_system | STACKIT MariaDB |  | UNKNOWN | DECISION_REQUIRED | NOT_PROVIDED | NOT_PROVIDED | NOT_PROVIDED |

• Sizing and availability

  shape_name, data_storage_size_in_gb and is_highly_available become the plan and storage you choose on STACKIT. The MariaDB page mentions primary-secondary, primary-primary and Galera replication in general; which one an instance offers is a question for the service plans.

• Backups and maintenance

  backup_policy.retention_in_days (14 in the demo) and maintenance.window_start_time (SUN 03:00) have no automatic carry-over. Set them on the target and write them down as requirements.

• Identity and placement

  admin_username and admin_password are replaced by a credential created for the MariaDB instance; availability_domain and subnet_id are replaced by the STACKIT network you build in the earlier waves.

• Data is a decision

  The mechanism, the downtime tolerance and the recovery point are all marked as not provided. The run suggests a logical dump; the size of the data and the window you can afford decide whether that is enough.

The move, in order

General practice around the run’s waves. The first three steps are the run’s own order; the rest is what an architect adds.

1. 01

   Build the network

   The VCN and the database subnet become STACKIT networks (waves 1 and 2).

2. 02

   Create the MariaDB instance

   Pick version and plan from the settings above and create the credentials (wave 3).

3. 03

   Test compatibility on a copy

   Restore a dump into the instance, for example with mysqldump and the mysql client, and run the application’s test suite against it.

4. 04

   Plan the connection pool

   The MariaDB page notes that the timeout for idle connections has been reduced to 60 minutes. Check that your connection pool recycles connections sooner.

5. 05

   Cut over with a way back

   Stop writes, take the final dump, load it, switch the application. Keep the OCI database untouched until the new one has carried real traffic.

Questions database owners ask

Sources

• STACKIT: MariaDB
• Oracle Cloud Infrastructure: MySQL HeatWave Service overview
• Oracle Cloud Infrastructure: HeatWave
• STACKIT: Virtual Network, concepts