Modern applications are expected to deliver instant responses while processing increasingly large volumes of data. Achieving this level of performance isn’t simply a matter of making the database faster. It requires placing the right workload on the right layer of the architecture.
Some operations require ultra-fast repeated reads, others demand transactional consistency, while analytical queries benefit from massively parallel in-memory processing.
This is precisely where OCI Cache and MySQL HeatWave complement each other.
OCI Cache provides a fully managed, high-performance caching layer compatible with Valkey and Redis environments, while MySQL HeatWave delivers a fully managed MySQL database with an integrated in-memory query accelerator capable of running transactional, analytical, machine learning, and AI workloads from the same database.
The real value isn’t choosing one technology over the other. It’s understanding that they solve different problems and that, when combined, they create a simple yet extremely powerful architecture.
OCI Cache accelerates data access. MySQL HeatWave accelerates data processing.
Together they provide exceptional performance while keeping the architecture straightforward, scalable, and easy to operate.
Far from being competitors, these two services are highly complementary. In this article, we’ll explore how they work together and why combining them can dramatically improve application responsiveness, database efficiency, and overall user experience.
What is OCI Cache?
OCI Cache is Oracle Cloud Infrastructure‘s fully managed in-memory caching service, powered by Valkey while maintaining compatibility with the Redis protocol.
Following Redis licensing changes, the open source community created Valkey under the Linux Foundation. Oracle became one of its major contributors and integrated Valkey directly into Oracle Cloud Infrastructure (OCI), providing developers with an enterprise-grade managed service while preserving compatibility with existing Redis applications.
For teams already familiar with Redis, migrating to OCI Cache typically requires little or no application changes.
Being a fully managed service, OCI Cache removes the operational burden of deploying clusters, configuring replication, handling failover, performing upgrades, and scaling infrastructure. Applications benefit from response times measured in microseconds to sub-millisecond latency, making it ideal for frequently accessed data.
Typical use cases include:
User sessions
Shopping carts
User profiles and preferences
Product catalogs
Feature flags
API response caching
Leaderboards
Rate limiting
Frequently accessed configuration data
…
Its mission is simple:
Keep the hottest application data in memory so it can be returned almost instantly while reducing the workload on the database.
What is MySQL HeatWave?
MySQL HeatWave is Oracle’s fully managed MySQL Database Service that natively integrates a massively parallel, in-memory query accelerator (the RAPID engine) directly with a standard MySQL database (via the reliable InnoDBengine).
Core Capabilities:
Dual Acceleration Architecture: Unlike traditional database systems that handle transactional and analytical processes completely separately, HeatWave uses an innovative in-memory engine to dramatically accelerate both standard transactional (OLTP) queries and complex reporting.
True Mixed Workloads (HTAP): It runs real-time transactional operations using InnoDB storage while concurrently routing heavy queries and analytics (OLAP) workloads to the integrated HeatWave Cluster.
Zero Code Changes: The query optimizer automatically decides whether to execute a query on standard InnoDB or route it to the massively parallel HeatWave cluster nodes. It accelerates standard MySQL queries by orders of magnitude, frequently turning long-running SQL operations into near-instantaneous responses, without altering a single line of your application code.
Moreover, MySQL HeatWave also includes integrated capabilities such as:
AutoML
Vector Store
GenAI
Lakehouse
JSON analytics
…
allowing developers to build modern AI-powered applications directly inside MySQL.
Complementary Services, Not Competing Ones
Because both OCI Cache and HeatWave rely heavily on memory, it’s easy to assume they solve the same problem. They don’t!
Their objectives are fundamentally different.
OCI Cache is an in-memory key/value store optimized for retrieving already-known data with extremely low latency.
MySQL HeatWave is an in-memory relational query engine optimized for executing SQL statements, joins, aggregations, and analytical queries over very large datasets.
Think of them as two different optimization layers.
OCI Cache & MySQL HeatWave: Head-to-Head Comparison
OCI Cache and HeatWave solve different problems, so it helps to compare them directly.
Aspect
OCI Cache
MySQL HeatWave
Primary role
Ultra-fast data access for repeated reads
High-speed transactional and analytical processing
Data model
NoSQL Key-Value
Relational tables with SQL
Latency profile
Microseconds to milliseconds
Milliseconds to seconds
Best suited for
User sessions, configuration flags, hot lookup results, …
OLTP, OLAP, AI, reporting
Consistency
Depends on cache strategy and invalidation
ACID transactions, durable
Query engine
Simple key-based access patterns
Full SQL + accelerated analytics
Operational goal
Reduce latency and offload MySQL
Accelerate computation
Scale Mechanism
Shards/replicas and vertical scaling
Scale the HeatWave cluster (nodes) independently of MySQL (read replicas)
As you’ve understood, both are in-memory technologies… but optimized for completely different access patterns.
A simple way to remember the difference:
OCI Cache answers
"Give me product #123."
MySQL HeatWave answers
"Show me the top twenty products purchased by customers living in France during the last two years."
Those are completely different workloads.
Choosing the Right Architecture
Depending on your workload, several architectures are possible.
MySQL HeatWave Only
Ideal when your application requires:
transactional consistency
query acceleration
operational reporting
real-time analytics
AI capabilities
The HeatWave Cluster accelerates SQL execution directly inside MySQL, making it an excellent solution for mixed OLTP/OLAP workloads.
However, HeatWave is not a cache.
Repeated requests for the exact same object still require SQL execution.
OCI Cache in Front of MySQL
This architecture shines for applications with many repeated reads.
Frequently requested objects are stored in OCI Cache, allowing subsequent requests to bypass MySQL entirely.
Benefits include:
dramatically lower latency
reduced database load
improved scalability
better user experience
The trade-off is that applications must manage cache expiration and cache invalidation.
OCI Cache + MySQL HeatWave
For many modern applications, this is the sweet spot:
HeatWave accelerates reporting, dashboards, AI, and complex SQL queries.
Each service focuses on what it does best.
A useful mental model is:
OCI Cache is the fastest path to already-known information.
while
MySQL HeatWave is the fastest path to discovering new information through SQL, analytics, and AI.
Why use both?
Using both services together creates a very balanced architecture. OCI Cache absorbs the repetitive reads that applications perform thousands of times every second.
Meanwhile, MySQL HeatWave focuses on:
transactional integrity
fresh data
analytical queries
dashboards
AI workloads
reporting
The combination is especially attractive when:
your application has a small set of extremely hot data;
you need operational dashboards;
you want to reduce database load;
you want analytics without introducing another database technology;
you prefer a simple, cloud-native architecture.
One way to visualize the relationship is:
OCI Cache reduces how often your application needs to ask the database the same question.
MySQL HeatWave dramatically improves how quickly the database answers every remaining question.
That’s not overlap, that’s architectural layering!
Advantages and Considerations
OCI Cache
Advantages
Extremely low latency
Redis/Valkey protocol compatibility
Fully managed
Reduces read pressure on database instances
Excellent horizontal scalability
Considerations
Adds cache invalidation complexity to application code
No persistence guarantee (ephemeral in nature)
Does not replace a persistent database
MySQL HeatWave
Advantages
SQL support
ACID compliance
Mixed OLTP, OLAP and AI workloads
High-performance analytics
Integrated Machine Learning and GenAI
Persistent storage
Considerations
Not intended for key/value caching
Slightly higher baseline network and query parsing overhead compared to pure memory lookups
Solves a different class of performance problems
Demo: A Python Glimpse at Latency
To show how simple it is to programmatically bridge these two layers, let’s look at a practical Python script.
Instead of mock data, this script connects to MySQL HeatWave using the MySQL Connector/Python to find a specific user, populates (seeds) the OCI Cache with that record as a JSON object using the valkey client, and then runs a back-to-back benchmark to demonstrate the latency difference between the two layers.
The goal isn’t to show MySQL is slow, its own read latency with a primary key is excellent, but to highlight the difference in speed a dedicated cache layer can provide for hot data.
import valkey
import mysql.connector
import time
import json
# ==========================================
# 1. CONNECTION SETUP
# ==========================================
# OCI Cache (Valkey) Connection
cache = valkey.Valkey(
host='abcdefghijklmno.redis.eu-frankfurt-1.oci.oraclecloud.com',
port=6379,
ssl=True,
decode_responses=True
)
# MySQL HeatWave Connection
def get_mysql_conn():
return pymysql.connect(
host='10.0.1.42',
user='dev',
password='My5U4€s3kret',
database='oci-cache_mysql-heatwave',
autocommit=True
)
# ==========================================
# 2. SETUP: SYNC DATA FROM MYSQL TO OCI CACHE
# ==========================================
USER_ID = 42
cache_key = f"user:{USER_ID}"
print(f"[*] Connecting to MySQL HeatWave to fetch data for user {USER_ID}...")
setup_conn = get_mysql_conn()
cursor = setup_conn.cursor(dictionary=True)
cursor.execute("SELECT id, name, role FROM users WHERE id = %s", (USER_ID,))
user_data = cursor.fetchone()
cursor.close()
setup_conn.close()
if not user_data:
raise ValueError(f"User with ID {USER_ID} not found in MySQL. Please verify your seed data.")
# Set the cache with the actual database payload
print(f"[*] Seeding OCI Cache (Valkey) with data from MySQL: {user_data}")
cache.set(cache_key, json.dumps(user_data))
print("[+] Cache primed successfully!\n")
# ==========================================
# 3. LATENCY BENCHMARK
# ==========================================
# --- SCENARIO A: Reading from OCI Cache (Valkey) ---
start_time = time.perf_counter()
cached_data = cache.get(cache_key)
cache_latency = (time.perf_counter() - start_time) * 1000 # Convert to ms
# --- SCENARIO B: Reading from MySQL (InnoDB) ---
conn = get_mysql_conn()
start_time = time.perf_counter()
cursor = conn.cursor(dictionary=True)
cursor.execute("SELECT id, name, role FROM users WHERE id = %s", (USER_ID,))
db_data = cursor.fetchone()
cursor.close()
db_latency = (time.perf_counter() - start_time) * 1000 # Convert to ms
conn.close()
# ==========================================
# 4. RESULTS
# ==========================================
print("--- Latency Benchmark Results ---")
print(f"OCI Cache (Valkey) Read: {cache_latency:.3f} ms")
print(f"MySQL (InnoDB) Read: {db_latency:.3f} ms")
print(f"Speedup Factor: {db_latency / cache_latency:.1f}x faster via Cache")
(venv) daz@sandbox:~/valkey$ python3 demo1_local.py
[*] Connecting to MySQL HeatWave to fetch data for user 42...
[*] Seeding OCI Cache (Valkey) with data from MySQL: {'id': 42, 'name': 'Olivier', 'role': 'admin'}
[+] Cache primed successfully!
--- Latency Benchmark Results ---
OCI Cache (Valkey) Read: 0.078 ms
MySQL (InnoDB) Read: 0.248 ms
Speedup Factor: 3.2x faster via Cache
What this tells us:
When you run this script, you will typically see OCI Cache returning data in fractions of a millisecond, while MySQL takes a few milliseconds.
For a CTO: That millisecond difference, multiplied by millions of daily active users, translates to a scalable architecture, massive infrastructure cost savings and a snappier user experience.
For a Developer: You get access to ultra-fast, microsecond APIs for fast user experiences alongside a fully robust, standard SQL database that seamlessly handles backend transactional logic and reporting.
For a DBA: You successfully offloaded millions of trivial SELECT statements away from your precious MySQL connection pool, keeping the database healthy for complex transactions and HeatWave analytics.
By running both services natively on OCI, you eliminate integration and management overhead, allowing you to focus purely on building fast, scalable applications.
Péroraison
OCI Cache and MySQL HeatWave are not competing services, they operate at different layers of the application stack.
OCI Cache minimizes application latency by serving frequently accessed data directly from memory, while MySQL HeatWave accelerates transactional processing, analytics, machine learning, AI, and SQL execution on persistent data.
Together they enable architects to design applications that are responsive, scalable, analytically powerful, and remarkably simple.
Perhaps the biggest advantage is that both are fully managed Oracle Cloud services. You don’t have to spend your time provisioning servers, configuring clusters, or managing failover. Instead, you can focus on what really matters: building applications that deliver value to your users.
In the end, it’s not about choosing between caching and database acceleration. It’s about using each technology where it delivers the greatest benefit.
MySQL Cloud AI & Analytics Solutions Architect at Oracle
MySQL Geek, strong interest in data and AI, author, blogger and speaker
I’m an insatiable hunger of learning.
—–
Leave a Reply