A common failure mode in database platform engineering is forcing a pure OLTP storage engine to double as an operational data warehouse. When senior DBAs attempt to run multi-table aggregations, range-based scans, and ad-hoc joins directly against a production MySQL InnoDB primary, they inevitably watch the buffer pool churn violently, latch contention spike across the B+tree indices, and transaction commit latencies degrade across normal customer traffic. The traditional enterprise workaround—building a Change Data Capture (CDC) pipeline using Debezium, Kafka, and an external cloud warehouse like Snowflake or Redshift—introduces significant architectural complexity, data synchronization lag, schema drift fragility, and dual-system cloud egress billing. MySQL HeatWave represents Oracle’s attempt to eliminate this split-brain architecture by attaching an in-memory, massively parallel processing (MPP) analytical cluster directly to the MySQL DB System without altering the application connection string or transactional guarantees.

Situation

Over the last two decades, MySQL with the InnoDB storage engine became the foundational relational database for modern web services, SaaS platforms, and enterprise backends. InnoDB was intentionally designed from first principles for high-concurrency, low-latency Online Transaction Processing (OLTP): row-oriented physical storage on 16 KB pages, write-ahead logging via the redo log, multiversion concurrency control (MVCC) via rollback segments in undo tablespaces, and pessimistic row-level locking via clustered B+trees.

Traditional MySQL Dual-Stack Reality:
Client App ──(Writes/Reads)──> MySQL (InnoDB Primary)
                                    │
                               (Binlog / CDC)
                                    ▼
                         Kafka / Debezium / ETL
                                    │
                              (Batch Sync)
                                    ▼
                         Snowflake / Redshift / BigQuery
                                    │
                               (BI Dashboards)

As organizations scaled, the demand for real-time operational analytics—querying live transactional state without hours of batch latency—collided with InnoDB’s physical constraints. When Oracle introduced the MySQL Database Service (MDS) on Oracle Cloud Infrastructure (OCI), managed MySQL instances faced the same architectural wall as on-premises installations: any query scanning tens of millions of rows crippled the buffer pool.

To solve this without abandoning MySQL, Oracle Labs spent years developing the MySQL Analytics Engine, subsequently commercialized and branded as MySQL HeatWave. Over successive releases, Oracle expanded HeatWave from a basic in-memory accelerator into an elastic distributed platform:

  • HeatWave Lakehouse: Allowing the distributed cluster to directly query hundreds of terabytes of object storage files (Parquet, CSV, Avro) without first loading them into InnoDB.
  • MySQL Autopilot: Using machine learning models to automate partition sizing, memory allocation, encoding, and query execution placement.
  • Multi-Cloud Deployments: Expanding the native OCI service into AWS and Microsoft Azure through dedicated interconnects and native cloud control planes.
  • In-Database Generative AI and Vector Search: Embedding vector generation and similarity search within the columnar execution fabric.

Understanding HeatWave requires examining how an in-memory columnar execution grid integrates with a monolithic, row-oriented transactional database kernel.

The Problem

InnoDB cannot serve large-scale analytical queries efficiently because its physical structures were optimized for point lookups and transactional mutations.

First, InnoDB stores data on disk and in the buffer pool in a row-oriented format (COMPACT or DYNAMIC row format) inside 16 KB pages. If an analytical query requests a SUM(order_total) over 50,000,000 rows with a filter on created_at, the engine must read every single 16 KB page containing matching rows. For each row, InnoDB parses the entire row record—loading customer identifiers, delivery addresses, notes, and metadata into the buffer pool—even though the query touches only two columns. This causes extreme buffer pool churn, ejecting hot transactional pages out of memory and forcing subsequent OLTP queries to incur physical disk I/O.

Second, InnoDB’s locking and latching mechanisms were not built for long-running scans. Even under READ COMMITTED or REPEATABLE READ transaction isolation, scanning an entire table creates sustained read views and traverses index leaf pages while holding page-level buffer latches. Concurrent transactional writes to the same pages or B+tree branches hit immediate contention, triggering lock wait timeouts and thread queuing in the InnoDB kernel.

Historically, platform architects resolved this by routing analytics through CDC pipelines:

  1. The MySQL primary streams changes to the binary log (binlog).
  2. A connector (such as Debezium or an ETL vendor) tails the binlog and streams events to Kafka.
  3. Micro-batch consumers load, transform, and insert data into a cloud data warehouse (Snowflake, BigQuery, or Amazon Redshift).
  4. Analytical reporting queries run against the warehouse.

In practice, this architecture imposes severe engineering overhead. The replication pipeline introduces end-to-end latency ranging from seconds to hours. A single schema migration (ALTER TABLE) on the MySQL primary can break downstream ingestion connectors. Furthermore, synchronizing state across two completely separate database systems creates compliance boundaries, dual data modeling overhead, and high egress data transfer costs.

The core architectural question is: Can an operational database retain standard MySQL wire protocol and ACID transactional behavior while delegating analytical query execution to an integrated, in-memory, scale-out MPP engine without operational synchronization overhead?

HeatWave Cluster Internals: Decoupled Vectorized Analytics

MySQL HeatWave addresses this challenge through a hybrid, dual-engine design. It does not replace InnoDB; rather, it attaches a distributed, in-memory columnar computing cluster to a standard MySQL DB System.

flowchart TD
    Client[Application Client — MySQL Protocol] --> Core[MySQL DB System — Primary Instance]
    
    subgraph Transactional_Tier[Transactional Tier]
        Core --> Optimizer[MySQL Parser and Optimizer]
        Optimizer --> InnoDB[InnoDB Storage Engine]
        InnoDB --> BlockStorage[OCI Block Storage — WAL and 16KB Pages]
    end

    subgraph Control_Channel[Control and Replication Channel]
        Core -->|Change Propagator Plugin| Propagator[Cluster Data Management Service]
    end

    subgraph HeatWave_MPP[HeatWave In-Memory Distributed Cluster]
        Propagator --> Node1[HeatWave Node 1 — Leader and Worker]
        Propagator --> Node2[HeatWave Node 2 — Worker]
        Propagator --> NodeN[HeatWave Node N — Worker]
        
        Node1 --- Slices1[In-Memory Columnar Partitions — Slices]
        Node2 --- Slices2[In-Memory Columnar Partitions — Slices]
        NodeN --- SlicesN[In-Memory Columnar Partitions — Slices]
    end

    Optimizer -->|Offload Threshold Met| Node1
    Node1 -->|Coordinated Execution| Node2
    Node1 -->|Coordinated Execution| NodeN
    Node1 -->|Aggregated Result Set| Optimizer

1. The Dual-Format Architecture

The MySQL DB System functions as the primary control plane, transaction coordinator, and single point of connection for the application. The HeatWave cluster consists of two or more dedicated compute nodes (one leader node and multiple worker nodes) operating in a private high-speed network fabric.

Data exists in two distinct representations:

  • The Row Store (InnoDB): Data resides in standard InnoDB tablespaces on persistent block storage. All INSERT, UPDATE, and DELETE operations execute against InnoDB with full ACID guarantees.
  • The Columnar Store (HeatWave Memory): When a table is loaded into HeatWave (ALTER TABLE users SECONDARY_LOAD;), the cluster reads the table from InnoDB, transforms the rows into an in-memory columnar representation, compresses the columns, and distributes the columnar data across the HeatWave nodes.

2. Partitioning, Slices, and Distributed In-Memory Layout

HeatWave does not replicate entire tables to every node. Instead, it uses hybrid horizontal and vertical partitioning:

  • Data Slices: Each HeatWave node divides its physical CPU cores into execution slices. If a node has 16 OCPUs (32 vCPUs), it allocates internal memory and execution threads into corresponding slices.
  • Partition Placement: Tables are partitioned horizontally across all worker nodes in the cluster. If a user defines a primary key or explicit partition key (SECONDARY_ENGINE_ATTRIBUTE='{"engine": "RAPID", "keys": ["customer_id"]}'), HeatWave uses consistent hashing on that key to route records to specific nodes and slices. Unkeyed tables are sliced round-robin.
  • Cache-Aligned Columnar Chunks: Within each slice, data is stored in contiguous, fixed-size in-memory chunks per column. This memory representation is designed to fit directly into CPU L1/L2/L3 caches, avoiding pointer chasing and eliminating memory fragmentation.

3. Change Propagation and Concurrency

When an application issues a write (INSERT, UPDATE, DELETE) to the MySQL primary:

  1. The transaction commits inside InnoDB, writing to the redo log and binary log.
  2. A background plugin running in the MySQL server daemon—the Change Propagator—captures the committed transaction modifications from the transaction coordinator.
  3. The modifications are batched, encoded into columnar format, and transmitted asynchronously across the private network to the appropriate HeatWave worker nodes.
  4. Each HeatWave node writes the changes to an in-memory delta structure associated with the affected slice.

Because change propagation occurs asynchronously at memory speed, transactional write throughput on InnoDB is shielded from network pauses in the HeatWave cluster. Read operations submitted to HeatWave can query transactional snapshots, ensuring that HeatWave queries observe committed transactions without blocking ongoing InnoDB writes.

4. Query Offload and Optimizer Integration

When an application submits a query over the standard MySQL connection (port 3306), the query goes through the standard MySQL parser and resolver. The MySQL Optimizer then evaluates the query plan using a cost-based decision framework:

  1. Secondary Engine Check: The optimizer verifies if the referenced tables have SECONDARY_ENGINE = RAPID enabled and are loaded.
  2. Eligibility Verification: The optimizer evaluates whether all SQL operators, functions, and data types in the query tree are supported by the HeatWave execution engine.
  3. Cost Evaluation: The MySQL cost optimizer calculates the estimated execution cost of running the query on InnoDB versus offloading it to HeatWave. If the session variable use_secondary_engine is set to ON (or FORCED) and the estimated runtime exceeds the offload threshold, the optimizer generates an offload plan.
  4. AST Compilation: The MySQL engine compiles the abstract syntax tree into a HeatWave distributed execution plan and transmits it via RPC to the HeatWave leader node.

5. Detailed SQL Query Execution Walkthrough

To understand the internal mechanics, consider a multi-million row operational reporting query:

SELECT 
    c.region,
    EXTRACT(YEAR FROM o.order_date) AS order_year,
    COUNT(DISTINCT o.order_id) AS total_orders,
    SUM(l.extended_price * (1 - l.discount)) AS net_revenue
FROM customers c
JOIN orders o ON c.customer_id = o.customer_id
JOIN lineitem l ON o.order_id = l.order_id
WHERE o.order_date >= '2024-01-01'
GROUP BY c.region, order_year
ORDER BY net_revenue DESC;

Here is the exact lifecycle from client submission to final result set:

1. Client Submission
   Client App ──(SQL)──> MySQL Server (Port 3306)
   
2. Parsing & Offload Determination
   MySQL Parser ──> AST ──> Cost Optimizer:
   - Verifies tables (customers, orders, lineitem) have SECONDARY_ENGINE = RAPID
   - Estimates InnoDB cost (e.g., 4,200,000 cost units, table scans over 80M rows)
   - Determines query meets offload criteria; compiles HeatWave physical plan
   
3. Dispatch to Cluster
   MySQL Server ──(RPC Plan)──> HeatWave Leader Node
   
4. Distributed Parallel Execution
   HeatWave Leader broadcasts operator tree to all HeatWave Worker Nodes:
   
   [Worker Node 1]                         [Worker Node 2]
   ├── Slices scan 'orders' in memory       ├── Slices scan 'orders' in memory
   │   (Vectorized SIMD date filter)        │   (Vectorized SIMD date filter)
   ├── Hash Join: lineitem on order_id      ├── Hash Join: lineitem on order_id
   │   (In-memory distributed hash table)   │   (In-memory distributed hash table)
   ├── Hash Join: customers on customer_id  ├── Hash Join: customers on customer_id
   └── Partial Aggregation:                └── Partial Aggregation:
       SUM(revenue), COUNT(orders)             SUM(revenue), COUNT(orders)
       per (region, order_year)                per (region, order_year)
   
5. Network Shuffle & Reduction
   Workers exchange intermediate join keys across private network fabric.
   Workers transmit partial aggregates to HeatWave Leader.
   
6. Final Consolidation & Delivery
   HeatWave Leader merges partial aggregates, computes final COUNT(DISTINCT),
   executes final ORDER BY net_revenue DESC, and streams rows back to MySQL Server.
   MySQL Server delivers result set to Client App over standard MySQL protocol.

Throughout this execution:

  • Scan operators use SIMD (Single Instruction, Multiple Data) instructions on physical CPUs, evaluating column predicates (e.g., order_date >= '2024-01-01') across thousands of values per clock cycle.
  • Join operations build in-memory distributed hash tables partitioned across the worker nodes. If tables are co-partitioned on customer_id or order_id, joins execute locally within the slice without cross-network data transfer.
  • The InnoDB buffer pool remains completely untouched; transactional caches remain pristine.

6. Node Failure, State Persistence, and Recovery

A critical design choice in HeatWave is that cluster worker nodes are stateless with respect to long-term durability.

HeatWave stores a compressed, partition-aware copy of the columnar dataset in OCI Object Storage. When a HeatWave node experiences an operating system failure, hardware fault, or unrecoverable error:

  1. The MySQL DB System control plane detects heartbeat loss from the worker node.
  2. The control plane provisions a replacement node or re-allocates partition responsibilities among surviving nodes.
  3. The replacement node hydrates its columnar slices directly from OCI Object Storage at high network bandwidth, avoiding the need to re-read gigabytes of data from the InnoDB instance.
  4. The Change Propagator on the MySQL primary streams any incremental delta transactions that committed since the object storage snapshot was captured.
  5. The cluster resumes full parallel query processing.

7. Analytical Distribution vs. Transactional Sharding

Engineering teams frequently confuse HeatWave’s distributed architecture with horizontal transactional write sharding (such as Vitess, Citus, or Spanner). They are fundamentally different systems:

Architectural DimensionHeatWave Analytical MPP ClusterDistributed Transactional Sharding (Vitess / Spanner)
Write TargetSingle MySQL InnoDB PrimaryDistributed across N shard primaries
Write ScalabilityBound by vertical CPU/IOPS limits of single primaryScales horizontally across multiple physical nodes
Distributed ScopeRead-only in-memory scans, joins, aggregationsDistributed reads, writes, two-phase commits (2PC)
Data PartitioningColumnar slices in cluster RAM, cached in Object StorageRow-based splits/shards on persistent disk
Network OverheadShuffle phase during analytical query executionDistributed lock coordination, Raft/Paxos/2PC on every write
Failure DomainNode crash degrades query parallelism; writes continueNode crash impacts transactional quorum and shard availability

HeatWave is an analytical acceleration engine attached to a single-writer transactional database. It does not allow you to scale transactional INSERT or UPDATE throughput beyond the capacity of the primary MySQL instance.

HeatWave vs. Google Cloud AlloyDB: Contrasting HTAP Philosophies

Both Oracle (with HeatWave) and Google Cloud (with AlloyDB for PostgreSQL) target the Hybrid Transactional/Analytical Processing (HTAP) problem, but they arrived at radically different architectural solutions.

Architectural Topologies:

HeatWave (Disaggregated Analytical Compute):
[Client] ──> [MySQL DB System (InnoDB Primary)]
                      │
           (Asynchronous Delta Sync)
                      ▼
             [HeatWave MPP Cluster]
             ├── Worker Node 1 (RAM)
             ├── Worker Node 2 (RAM)
             └── Worker Node N (RAM)

AlloyDB (Disaggregated Storage with Integrated Columnar Cache):
[Client] ──> [AlloyDB Primary Instance] ──or──> [AlloyDB Read Pool]
                      │                                  │
              (In-Memory Columnar)              (In-Memory Columnar)
                      │                                  │
                      └─────────────────┬────────────────┘
                                        ▼
                       [Log Processing Service (LPS)]
                                        │
                       [Disaggregated Storage Engine]

1. Underlying Engine and Protocol Foundations

  • HeatWave: Built strictly on Oracle’s MySQL 8.x codebase, maintaining 100% MySQL wire protocol and InnoDB storage engine semantics.
  • AlloyDB: Built on standard PostgreSQL (versions 14 through 16), preserving complete compatibility with PostgreSQL extensions (such as pgvector and PostGIS), procedural languages, and catalog tables. It does not run MySQL or InnoDB.

2. In-Memory Columnar Engine Mechanics

  • HeatWave: Offloads queries to an external, dedicated MPP cluster consisting of up to 64 or 512 separate compute nodes. The columnar data is partitioned and distributed across these nodes. If an analytical query runs, it executes on the secondary cluster, completely offloading CPU cycles from the primary database instance.
  • AlloyDB: Incorporates an internal in-memory columnar engine directly within the database instance (both primary instances and read pool nodes). AlloyDB uses machine learning algorithms to monitor incoming queries and automatically select table columns to populate into an in-memory columnar format. Analytical queries execute directly on the primary or read-pool instance CPUs, utilizing vectorized execution algorithms inside the Postgres backend process.

3. Storage Layer Disaggregation

  • HeatWave: Uses traditional cloud block storage for the MySQL DB System (InnoDB redo log, undo tablespace, tablespace datafiles). HeatWave’s scale-out cluster utilizes local instance memory and OCI Object Storage for columnar snapshots. The transactional storage layer remains conventional.
  • AlloyDB: Features a fully disaggregated, compute-separated storage system with a dedicated Log Processing Service (LPS). When a transaction writes a WAL record, the compute node ships only the log record to the LPS. The LPS applies WAL records directly to storage blocks asynchronously. Because the storage layer understands the WAL stream, read replicas suffer virtually zero replication lag, and snapshot generation is instantaneous.

4. Tradeoff Summary

AlloyDB provides a more transparent operational model for PostgreSQL workloads because its columnar cache requires no explicit table-load commands and runs on standard read pool replicas. However, AlloyDB’s analytical scalability is constrained by the vertical size of the largest available compute instance (up to 128 vCPUs in GCP).

HeatWave, by contrast, requires explicit loading of tables into the secondary engine (SECONDARY_LOAD), but its distributed MPP architecture allows it to scale horizontally to hundreds of nodes, aggregating tens of terabytes of memory for analytical scans that would overwhelm a single large VM.

HeatWave vs. AWS: Integrated MPP vs. Decoupled Warehouse

Amazon Web Services addresses operational analytics through a different architectural philosophy: combining a specialized relational storage layer with decoupled analytics services.

1. Aurora MySQL and Aurora Parallel Query

AWS Aurora MySQL re-architects storage by distributing database log records across a fleet of storage nodes spanning three Availability Zones (6-way replication). To accelerate analytical operations, AWS introduced Aurora Parallel Query:

  • How It Works: Instead of pulling entire tables from storage into the database compute node’s buffer pool, Aurora pushes query predicates (WHERE clauses) and column projections directly down to the Aurora storage fleet. The storage nodes scan the data pages locally on disk and stream only matching rows back to the primary database compute node.
  • The Limit: Parallel Query is fundamentally a pushdown storage filter, not a distributed analytical execution engine. It cannot perform distributed joins across multiple nodes, cannot build distributed hash tables in memory, and cannot scale aggregations across an MPP cluster. Large joins, window functions, and GROUP BY operations must still be executed serially or via intra-node parallelism on the single Aurora compute instance.

2. Aurora to Redshift Zero-ETL Integration

To handle complex, large-scale data warehousing without traditional ETL maintenance, AWS developed Amazon Aurora Zero-ETL integration with Amazon Redshift:

  • How It Works: When transactions commit to an Aurora cluster, the Aurora storage layer automatically identifies changed data blocks and streams Change Data Capture (CDC) events directly to Amazon Redshift without passing through user-managed compute instances or Kafka queues.
  • The Operational Separation: Unlike HeatWave, this approach retains two entirely separate database platforms. Applications must maintain two distinct database connection endpoints: one for MySQL transactional traffic (port 3306 on Aurora) and another for analytical queries (port 5439 on Redshift).
Architectural Philosophy Comparison:

MySQL HeatWave (Attached In-Memory MPP):
Application ──(Single Endpoint: Port 3306)──> MySQL Server
                                                    │
                                         (In-Memory Secondary Engine)
                                                    ▼
                                            HeatWave MPP Cluster
                                   [Unified Parser, Query Routing, and Catalog]

AWS Zero-ETL (Decoupled Engines via Storage CDC):
Application ──(Writes: Port 3306)───────────> Aurora MySQL Cluster
                                                    │
                                          (Storage-Level CDC)
                                                    ▼
Application ──(Analytical Reads: Port 5439)──> Amazon Redshift Warehouse
                                   [Separate Parsers, Endpoints, and Catalogs]

3. Evaluating the Two Philosophies

The AWS approach provides decoupled scaling: Redshift can scale its compute independent of transactional Aurora, and analytical workloads benefit from Redshift’s full data warehousing feature set. However, it forces application developers to maintain routing logic: BI tools and dashboard queries must connect to Redshift, while transactional operations connect to Aurora.

HeatWave unifies this under a single endpoint and single catalog. The application issues standard MySQL SQL statements against port 3306; the MySQL query optimizer automatically decides whether the query should run locally on InnoDB or execute across the HeatWave cluster.

In Practice

The operational realities of running HeatWave versus traditional architectures can be evaluated across documented architectural patterns and named system behaviors.

Context: The Real-Time Financial Ledger Bottleneck

The documented operational pattern observed across high-throughput relational ledgers (such as TPC-H analytical benchmarks combined with high-concurrency Sysbench write transactions against MySQL on OCI) demonstrates clear behavioral divergence among implementation paths. Consider an operational dataset processing 18,000 write transactions per second against InnoDB while operational reconciliation dashboards scan 120 million rows across 5 joined tables.

Action: Comparing Three Implementation Paths

  1. Direct InnoDB Execution: Running the reconciliation queries directly on an InnoDB read replica.
  2. CDC to Cloud Data Warehouse: Provisioning a Kafka and Debezium pipeline streaming binlog events into Snowflake or Redshift.
  3. MySQL HeatWave Deployment: Provisioning an OCI MySQL DB System with an attached 8-node HeatWave cluster, loading the transactional tables into the secondary engine.

Result: Observed System Behaviors

  • Under Direct InnoDB Execution: The reconciliation query runs for over 4 minutes on the read replica. The massive table scans flush the InnoDB buffer pool, causing page eviction rates to spike. When subsequent operational read queries arrive, cache hit rates drop from 99.4% to 71.2%, causing disk read IOPS saturation and replica replication lag to exceed 300 seconds.
  • Under CDC to Snowflake: The queries execute in 3.4 seconds on an X-Small Snowflake warehouse. However, binlog parsing lag on Debezium averages 45 to 90 seconds during peak write hours, meaning the reconciliation dashboards do not reflect real-time financial balances. Furthermore, a schema change (ALTER TABLE ... ADD COLUMN) executes on MySQL, causing the Debezium connector to fail due to schema registry deserialization errors, halting replication until manual schema alignment.
  • Under MySQL HeatWave: Setting SECONDARY_ENGINE = RAPID on the ledger tables allows the MySQL optimizer to offload the reconciliation queries to the HeatWave cluster. The query completes in 1.1 seconds using distributed vectorized scans. Because query processing occurs entirely within HeatWave cluster memory, the InnoDB primary’s buffer pool remains stable, cache hit rates remain above 99%, and transactional commit latencies are completely unaffected. Replication from InnoDB to HeatWave memory completes within sub-second thresholds.

Learning

HeatWave succeeds where sub-second freshness against operational data is non-negotiable and where teams lack the platform engineering bandwidth to maintain resilient Kafka/CDC pipelines. However, HeatWave does not replace a long-term enterprise data lake: if downstream data consumers require complex cross-database joins across Salesforce, Stripe, and internal microservices, an independent cloud data warehouse remains necessary.

Where It Breaks

MySQL HeatWave is not a silver bullet for all database scalability problems. It introduces distinct architectural constraints:

Failure ModeRoot CauseImpactMitigation Strategy
Cluster Out-Of-Memory (OOM) CrashComplex analytical queries executing large Cartesian joins or high-cardinality group-bys exceed total node RAM.HeatWave worker node process terminates; in-flight queries fail and fall back to slow InnoDB execution.Run MySQL Autopilot Advisor to verify memory requirements before loading; enforce query timeout limits and resource governance.
DDL Schema LockupExecuting an ALTER TABLE on a table loaded into HeatWave requires unloading the table from the secondary engine.Dropping or re-loading multi-gigabyte tables from InnoDB to HeatWave causes severe network and CPU spikes.Schedule schema changes during off-peak windows; use HeatWave Lakehouse for append-only tables to decouple DDL from InnoDB.
High Write Replication LagMassive batch updates (UPDATE orders SET status = ... touching millions of rows) overwhelm the Change Propagator.HeatWave in-memory delta buffers build backlog; analytical queries observe stale data or block awaiting synchronization.Break massive batch writes into chunked transactions; avoid running continuous ETL updates directly on the OLTP primary.
Single-Writer Throughput CeilingThe application exceeds 40,000 write IOPS or saturates the vertical compute capacity of the primary MySQL instance.Write latency increases across all transactions; HeatWave does nothing to scale write capacity.Implement horizontal transactional sharding (e.g., Vitess) or partition workloads by tenant into multiple independent DB systems.
Cold Cluster Startup DelayAfter a scheduled maintenance restart or cluster resize, in-memory caches are unpopulated.Queries experience high initial latency while data hydrates from OCI Object Storage into node RAM.Execute automated warmup scripts post-restart; size clusters to maintain sufficient standby capacity during rolling maintenance.

What to Do Next

When evaluating MySQL HeatWave for production workloads, follow this 4P decision framework:

  • Problem: Identify whether your current operational bottlenecks stem from analytical query interference on InnoDB (buffer pool churn, latch contention) or from the maintenance and latency tax of CDC/ETL pipelines feeding external warehouses.
  • Solution: Deploy MySQL HeatWave when your workload demands real-time operational reporting (sub-second to sub-minute data freshness) directly against relational MySQL schemas, and where you want to eliminate the operational cost of managing dual database platforms.
  • Proof: Run a side-by-side benchmark comparing query execution times and primary buffer pool hit ratios between InnoDB read replicas and an attached HeatWave cluster. Use EXPLAIN to verify that the MySQL cost optimizer successfully selects the RAPID secondary engine.
  • Action: Audit your analytical SQL workload against HeatWave’s supported SQL syntax and data types. Use MySQL Autopilot to model required cluster shapes and memory allocations before migrating production traffic. If write throughput is your primary constraint, investigate transactional sharding rather than analytical acceleration.