Readyset Private on Azure VM: A Hands-On Guide to Caching Performance (MySQL Edition)
6 min read
•
26 days ago

"What if scaling reads didn’t require replicas, rewrites, or added infrastructure complexity? This post walks you through running Readyset—a caching layer purpose-built for real-time SQL acceleration—on Azure VM with MySQL. In just a few commands, you'll launch a MySQL database, deploy Readyset, and witness query speeds drop from milliseconds to microseconds."
Prerequisites
Before we dive in, ensure you're authenticated with Azure and have a role that includes permission to:
- Create Azure Database for MySQL flexible server instances
- Create and SSH into VMs
- Access and manage networking (if needed)
Install the Azure CLI and run:
Part 1: Create a MySQL Database on Azure
Step 0: Enable MySQL Resource Provider
Before creating a MySQL server, ensure the MySQL namespace is registered for your subscription:
This step is required only once per subscription. If not done, you may encounter a MissingSubscriptionRegistration
error.
Step 1: Create a Resource Group
In Azure, a resource group acts as a logical container for related resources like databases, virtual machines, and networking components. Grouping resources makes management and cleanup easier, especially for demos or projects with a defined lifecycle.
Step 2: Create a MySQL Flexible Server
If successfully created, you should be able to view the database directly in the azure portal.
Now retrieve the hostname of the database server:
Verify the MYSQL connection:
Create a new database and load it with the readyset quickstart IMDB dataset:
Note: After loading the dataset, ensure the title_basics
table has a primary key on tconst
(to avoid Azure's hidden primary key).
Part 2: Launch and Configure Readyset on an Azure VM
Step 1: Provision a simple Ubuntu VM to run Readyset:
SSH into the instance:
You can connect using password authentication via the public IP of the VM.
- Get the public IP:
- Then connect from your terminal using:
Step 2: Install MySQL Client and Readyset on Ubuntu 24.04
Step 3: Download Azure CA Certificate
Download the Azure Database for MySQL CA certificate (note: all Azure Flexible MYSQL Databases require an SSL cert in order to connect):
Step 4: Run Readyset
Launch Readyset with the following command:
Note: this will run Readyset in a detached state so that we can connect to it from the same terminal window. Any unexpected startup errors will be visible in readyset.log
Part 3: Cache Queries and Measure Performance
With Readyset running, let's walk through caching a query and observing the performance improvement.
Step 1: Connect to Readyset
Connect to Readyset via it’s caching ddl port (note: connecting on this port is necessary for applications to cache queries):
Step 2: Run a query and measure performance
The below query grabs the top 10 movies between the years 1950 and 2000 where the number of votes is greater than 1000, sorted by average rating:
Before caching, this query takes an average of ~800
- ~1700
ms depending on active database load.
Step 3: Cache the Query
To cache a query in readyset, identify the query's ID for caching:
Note: the ‘readyset supported’ column indicates whether the query can be cached. If you’ve loaded your own dataset and sent Readyset a custom query, try to cache the query and observe the output. If the query is not supported it will provide a reason and tips to modify the query so it can be cached.
Create a cache for the query
Then confirm that it has been successfully cached
Step 4: Rerun the Query and Observe the Speedup
Run the same query again and observe the reduced execution time (e.g., <0.01
seconds).
This is a small demonstration of the power of Readyset's caching acceleration. Instead of proxying the query to your upstream MySQL database, Readyset serves query results directly from its intelligent, materialized cache. This not only accelerates query performance dramatically but also reduces the general load on your primary database.
Unlike traditional caching mechanisms (e.g., Redis or manual materialized views), Readyset automatically keeps cached results up to date by listening to the database's change streams (binlog for MySQL or WAL for Postgres). This ensures your application always gets fresh, low-latency responses without complex invalidation logic.
Cleanup Resources
Once you're done, you can delete the entire resource group to remove all associated resources (MySQL flexible server, VM, networking, etc.):
This ensures you don't incur any ongoing charges for the resources created in this demo.
Conclusion: Platform-Independent and Future-Ready
While this guide focused on deploying Readyset alongside Azure MySQL, Readyset is a platform-independent solution. It integrates seamlessly with MySQL and PostgreSQL deployments—whether they run on Azure, AWS, GCP, or on-premises environments. You can introduce Readyset into your existing infrastructure without rewriting your application code.
Additionally, the Readyset team is actively working on expanding support for native cloud deployments across providers, including Azure. Soon, you'll be able to deploy Readyset clusters directly into Readyset's managed environment, or directly into your own cloud account for even simpler setup and scaling.
By leveraging Readyset, you gain:
- Dramatic read latency reductions (from seconds to milliseconds or microseconds)
- Reduced database load and costs (fewer replicas, lower infrastructure overhead)
- Fresh, up-to-date cached query results without manual intervention
Try Readyset today and see how easily it can slot into your data architecture to turbocharge your SQL performance–without any code changes!
Questions, comments? Join the discussion on Readyset community slack channel here or sign up for a demo and free query assessment here. You can also follow us on LinkedIn.
Authors