Marcelo AltmannBrowse our articles
Discover insights, tutorials, and the latest from Readyset's blog.

In this ninth post of our series, we decode the XID_EVENT — the smallest event in the binary log, and the one that marks every transactional commit. Introduction Every DML transaction we've decoded so far ends the same way: with an XID_EVENT (event type 16, 0x10). At only 31 bytes on the wire, it carries a single piece of information — an 8-byte transaction identifier — but it does some of the heaviest lifting in MySQL replication. The XID_EVENT is what allows replication to be crash-safe wit
Marcelo AltmannRecent articles

In this ninth post of our series, we decode the XID_EVENT — the smallest event in the binary log, and the one that marks every transactional commit. Introduction Every DML transaction we've decoded so far ends the same way: with an XID_EVENT (event type 16, 0x10). At only 31 bytes on the wire, it carries a single piece of information — an 8-byte transaction identifier — but it does some of the heaviest lifting in MySQL replication. The XID_EVENT is what allows replication to be crash-safe wit
Marcelo Altmann
Readyset has always been about making database scaling effortless. Today, we’re extending that mission from the server to the developer’s terminal with rdst, a production-native, AI-powered CLI that helps teams write better queries, diagnose performance issues, and close the loop on caching, all before bad queries ever reach production. The Database Scaling Problem Is a Query Problem Every engineering team eventually hits the same wall: the database can’t keep up. Latency spikes. CPU climbs.

Why Query Rewriting Matters for Dataflow Most databases work the same way: a query arrives, the engine builds an execution plan, scans tables, joins rows, filters, aggregates, and returns the result. Every time the query runs, the work repeats from scratch. This pull-based model has served relational databases for decades, but it carries an inherent cost: read latency is proportional to the complexity of the query and the size of the data it touches. Readyset takes a fundamentally different ap
All articles

In this ninth post of our series, we decode the XID_EVENT — the smallest event in the binary log, and the one that marks every transactional commit. Introduction Every DML transaction we've decoded so far ends the same way: with an XID_EVENT (event type 16, 0x10). At only 31 bytes on the wire, it carries a single piece of information — an 8-byte transaction identifier — but it does some of the heaviest lifting in MySQL replication. The XID_EVENT is what allows replication to be crash-safe wit
Marcelo Altmann
Readyset has always been about making database scaling effortless. Today, we’re extending that mission from the server to the developer’s terminal with rdst, a production-native, AI-powered CLI that helps teams write better queries, diagnose performance issues, and close the loop on caching, all before bad queries ever reach production. The Database Scaling Problem Is a Query Problem Every engineering team eventually hits the same wall: the database can’t keep up. Latency spikes. CPU climbs.

Why Query Rewriting Matters for Dataflow Most databases work the same way: a query arrives, the engine builds an execution plan, scans tables, joins rows, filters, aggregates, and returns the result. Every time the query runs, the work repeats from scratch. This pull-based model has served relational databases for decades, but it carries an inherent cost: read latency is proportional to the complexity of the query and the size of the data it touches. Readyset takes a fundamentally different ap

Most LLM-generated SQL doesn't fail. It runs and returns results, and that's exactly what makes it dangerous. The errors don't surface until they're already in your data. AI-assisted development has made it easier than ever to generate SQL quickly. The problem is that quick and correct are not the same thing, and with databases, the gap between the two has consequences that compound quietly over time. SQL that runs is not the same as SQL that works. LLMs are good at producing SQL that looks ri

MySQL 9.7.0 LTS landed today, and we had the pleasure of watching the announcement live — and we were the first ones to download. If you've already pulled the binaries and you're poking at it in a lab, here's the news: Readyset already supports it. The point isn't that Readyset happens to work with 9.7. The point is that we were prepared for the launch. Our compatibility matrix has been running 9.7 pre-release builds, so the same readysettech/readyset:latest image you can docker pull right now

One of the most requested features since Readyset first supported MySQL has been GTID-based replication. With the latest release, Readyset now fully supports MySQL Global Transaction Identifiers (GTIDs), and with it, a capability that changes how you think about cache durability: zero-downtime failover. This post covers what GTID support means for Readyset users, how failover works in practice, and why this matters for anyone running Readyset in production. The Problem with Binlog File and Po
Marcelo Altmann
In this eighth post of our series, we decode the three row events — WRITE_ROWS_EVENT, UPDATE_ROWS_EVENT, and DELETE_ROWS_EVENT — that carry the actual row data for INSERT, UPDATE, and DELETE operations in row-based replication. Introduction In the previous posts, we decoded the events that set the stage for row-based replication: the GTID_LOG_EVENT identifies the transaction, the QUERY_EVENT opens it with BEGIN, and the TABLE_MAP_EVENT describes the table's schema. Now we finally arrive at th
Marcelo Altmann
In this seventh post of our series, we decode the TABLE_MAP_EVENT — the event that maps a numeric table ID to a database/table name and the column layout that the row events immediately following it will reference. Introduction The TABLE_MAP_EVENT (event type 19, 0x13) is essential for row-based replication. It appears before any row event (INSERT, UPDATE, DELETE) and provides: * Table identification: Database name, table name, and a numeric table ID * Column metadata: Number of columns an
Marcelo Altmann
We kept hearing the same thing from customers: "We already know which queries need caching. Why do we need to go through the DBA to set it up?" Fair point. So we built Query Hints: The Old Way Was Slow for the Wrong Reasons Caching a query in Readyset used to require someone — usually a DBA or platform engineer — to connect to Readyset and run a CREATE CACHE statement. That works fine if you have a small, stable set of queries and an ops team with bandwidth. In practice, though, the bott
Marcelo Altmann
In this sixth post of our series, we decode the QUERY_EVENT — the workhorse event that records DDL statements and transaction boundaries. Introduction The QUERY_EVENT (event type 2, 0x02) is one of the most versatile events in a binary log. It records: * DDL statements: CREATE, ALTER, DROP, TRUNCATE, etc. * Transaction boundaries: BEGIN statements that start a transaction * Statement-based DML: In statement-based replication mode, INSERT/UPDATE/DELETE Even in row-based replication (the d
Marcelo AltmannSpring is here, and March kept us busy. Grab a coffee and see what the Readyset team has been up to. Hussle Technology Eliminates Peak-Season Database Load with Readyset Hussle Technology, a global leader in direct sales and field-sales enablement software, was facing a familiar problem: seasonal spikes in customer activity were pushing their primary MySQL database toward saturation at exactly the wrong moments, peak revenue windows. After deploying Readyset QueryPilot, those same workload

In this fifth post of our series, we decode the GTID_LOG_EVENT — the event that marks every transaction with a globally unique identifier. Introduction Every transaction in a GTID-enabled MySQL server begins with a GTID_LOG_EVENT (event type 33, 0x21). This event assigns a globally unique identifier to the transaction, consisting of: * SID (Source ID): The UUID of the server that originally committed the transaction * GNO (Group Number): A monotonically increasing sequence number Together
Marcelo Altmann
In this fourth post of our series, we decode the PREVIOUS_GTIDS_LOG_EVENT — the event that tracks which GTIDs were recorded in prior binary log files, enabling replicas to determine their starting point. Introduction When MySQL rotates to a new binary log file, it needs to record which transactions have already been committed in previous files. This is the job of PREVIOUS_GTIDS_LOG_EVENT—it appears near the beginning of every binlog file (right after the FORMAT_DESCRIPTION_EVENT) and contains
Marcelo Altmann
In this third post of our series, we decode the FORMAT_DESCRIPTION_EVENT — the critical first event in every binary log that tells us how to interpret everything that follows. Introduction The FORMAT_DESCRIPTION_EVENT (FDE) is arguably the most important event in a binary log. It's always the first event after the magic number, and it serves as a self-describing header for the entire file. Without it, we wouldn't know: * Which version of the binary log format we're dealing with * What MySQ
Marcelo AltmannIt’s been a busy month with lots of updates, let’s dive into them: Readyset Shallow Cache This month we introduced Readyset Shallow Cache, a new caching layer designed to expand Readyset’s query coverage. Readyset’s deep caching engine has always delivered sub-millisecond performance for operational queries that require ultra-low latency refresh. But many production databases serve a mix of operational and analytical queries from the same system. Shallow Cache complements Deep Cache by accel

Readyset has always been defined by our incremental dataflow engine. It compiles your SQL into a dataflow graph where base table nodes ingest the replication stream (binlog/WAL) from tables being replicated to Readyset. Internal nodes apply joins, filters, and aggregates, while reader nodes hold the materialized result. Because writes flow through the graph and only affected nodes are updated via incremental view maintenance, the cache stays updated in real-time. Reads are simple lookups on the

In this second post of our series, we examine the binary log file header and the 19-byte common event header that every event shares. The Binary Log File Header (Magic Number) Every MySQL binary log file begins with a 4-byte magic number that identifies it as a binary log: Bytes Hex ASCII Meaning 4 FE 62 69 6E .bin Unencrypted binary log 4 FD 62 69 6E .bin Encrypted binary log The first byte distinguishes encrypted (0xFD) from unencrypted (0xFE) logs. For encrypted logs, an
Marcelo Altmann
In this blog post, we are going to use "Vibe Coding" to build an application and explore Readyset QueryPilot, a tool designed to automatically analyze and cache queries in a MySQL workload. The goal is to prove that even for automated queries with no human interaction, QueryPilot can automate query caching and improve performance. QueryPilot automatically identifies which queries should be cached and recommends the appropriate strategy, either deep caching or shallow caching. This automation de

This is the first post in a series where we dive deep into the MySQL binary log format. We'll manually read binary log files byte by byte to understand exactly what goes under the hood of MySQL replication. Introduction Have you ever wondered what's actually inside a MySQL binary log? Sure, you can use mysqlbinlog to decode events, but what if you wanted to parse them yourself? Whether you're building a Change Data Capture (CDC) system, debugging replication issues, or just curious about MySQ
Marcelo Altmann
For years, MySQL users working with Change Data Capture (CDC), and replication environments have dealt with a fundamental architectural limitation: foreign keys were handled by the Storage Engine (InnoDB) and cascading operations were invisible to the binary log. MySQL 9.6, released January 20, 2026, addresses this long-standing issue by moving foreign key enforcement from the InnoDB storage engine to the SQL layer. This post examines the technical details of this change, its implications for r
Marcelo AltmannLet’s dive into our first product update of 2026! 💬 Product Updates Readyset Core * MySQL Replication Server UUID Support: Added the --replication-server-uuid option to set a server UUID in MySQL. This UUID is now reported in SHOW REPLICAS. * OOM Prevention for Large Parameterized IN Predicates: Fixed potential out-of-memory errors by rejecting queries with parameterized IN predicates that would expand to too many lookup keys. * Configurable Sampler Query Timeouts: Added support for conf

(Mistakes and em-dashes are my own.) We have a Claude Code command in our monorepo which is a good example of what I’m calling the "80/20 token rule": if it takes 20M LLM tokens to write a feature, you should spend 80M on ensuring quality: safety measures, testing, and of course code review. If software quality was an open problem before, then agentic engineering has blown it even more wide opener. At a high level, here's what it does: 1. Read the patch to review and all related code. 2. Ha
For a long time, most serious database incidents shared a common root cause: a human made a mistake. It could be a poorly written query that caused a spike or a permission was too broad or maybe a review didn’t happen. Database security models, operational processes, and tooling were all built around that assumption. Humans were the risk, and humans were also the control. That assumption is starting to break down. Today, more and more SQL is generated without a human author. What used to be 1
Tanmay SinhaThe OpenAI Postgres scaling article has been making the rounds, and for good reason. The piece does two things extremely well. First, it shows just how Postgres can be pushed far beyond what most teams assume is possible. Second, it makes clear that workloads at this scale don’t run on databases alone; they rely on caching, proxies, and careful query traffic management. It’s a rare public look at what it actually takes to run Postgres at serious scale. Why Scaling PostgreSQL at High Traffic
Gautam GopinadhanWe embarked on an exercise to predict how Enterprise infrastructure (including data infrastructure), will change with AI. Along the way, we made several observations about software and processes in general. I'm noting some of these below. Some of these are fresh takes, and we haven't seen them discussed elsewhere, so we would love to hear different perspectives on them. In this article, we refer to both the use of AI to write software, as well as to execute processes and workflows, i.e. Agents.
Gautam Gopinadhan2025 was the year we started noticing things we couldn’t easily explain away. We shipped a lot, but what stuck with us were the patterns we kept seeing in production. Traffic didn’t line up with application releases. Queries that looked reasonable in isolation would end up destabilizing databases once deployed. In many cases, it looked like the usual tension between application teams moving quickly and database or platform teams trying to keep systems stable. Application teams weren’t just shi
As we sled our way into the holiday season, here’s what’s new at Readyset: 💬 Product Updates Readyset Core * Smarter Table Renames: Readyset now detects RENAME TABLE and ALTER TABLE ... RENAME TO operations and automatically re-snapshots the affected tables, maintaining cache consistency even as schemas change. * PostgreSQL Array Support: We added support for PostgreSQL-style array constructor syntax, improving compatibility with modern Postgres applications and enabling more expressive q

Readyset is a cache layer that sits between the application and the database, acting as a cache for supported queries and proxying unsupported queries upstream. This means that any query Readyset supports is theoretically supported by the upstream database, but not necessarily the other way around. What if that is no longer the case? What if Readyset can support queries that the upstream database can’t? What if you could keep your relational database and add extra functionality without any plug
Mohamed AbdeenAs traffic spikes approach for the holiday season, we’ve rolled out new improvements to help you keep database performance fast and predictable. Here’s what’s new: 💬 Product Updates Readyset Core * Smarter Time-Series Aggregations: We introduced Bucket(timestamptz, interval), a Readyset-specific SQL function that groups timestamps into fixed intervals. It’s ideal for time-series queries like metrics rollups or activity heatmaps. This makes it easier to analyze trends over time without rest

It Might Be Time to Rethink How You Scale MySQL for Peak Demand As Black Friday and Cyber Monday approach, many engineering teams prepare for their annual database performance stress test. The surging traffic, unpredictable spikes, and sleepless nights spent watching database dashboards. The typical response is familiar: add more replicas, increase compute resources, and pray everything holds. But this approach to database scaling is reactive, costly, and fragile. What begins as a quick fix be
Tanmay Sinha
How Readyset Supports and Optimizes Window Functions Window Functions are an integral part of SQL performance and query optimization, and they're widely supported in production databases today. To achieve our goal of helping our users scale their MySQL and PostgreSQL databases with no code changes, we now support SQL Window Functions as a native part of Readyset. Although we now support standard SQL Window Functions with no code changes, in this blog, we will discuss some of the performance o
Mohamed AbdeenSpooky season is here, and so are the latest updates from Readyset: QueryPilot Demo: It's Not Broken, It's Just That Fast. QueryPilot automatically finds and optimizes your most expensive queries with zero manual tuning or configuration. Its performance is so instant that results are ready before you even realize the query ran. In this demo, Tanmay and Mike show how simple it is to get started with QueryPilot, and how effortlessly you can scale workloads. MySQL users → Join the beta, fi
Obrigado por participar do MySQL BR Conf 2025 e celebrar os 30 anos do MySQL! Tivemos um tempo fantástico conectando com vocês e mal podemos esperar para ver os resultados do desafio. Como participar para ter a chance de ganhar um prêmio em dinheiro de R$ 500* Passo 1: Cadastre-se ou faça login em readyset.cloud. Passo 2: Crie seu cluster de demonstração: no painel, clique em “Create demo cluster”, dê um nome para o projeto, escolha seu banco de dados e então clique em “Create”.. Passo 3
As the world starts adding Earth, Wind and Fire back on to their playlists, here’s what’s new at Readyset: Scaling WordPress Instantly with Readyset QueryPilot Last month we launched Readyset QueryPilot, our zero-touch automatic caching solution, in beta for MySQL and early results are in. In a recent test on WordPress, QueryPilot instantly scaled database performance impressively without a single code change, delivering: * ~60% higher throughput: requests per second increased from 25.6 →

How often do you think about alphabetization? Software engineers don’t typically think a lot about it. How hard can it be to sort 26 letters, or maybe twice as many if you count lower and upper case? But examination of real world alphabetization quickly reveals that the problem is not trivial. Here’s a photograph of part of the index at the end of the Gang of Four’s book Design Patterns. Right away, you can see that the cases are all mixed up. The lowercase Bs are mixed in with the capital

We're excited to announce that Readyset now supports SQL Window Functions. This powerful addition means you can now cache more of your complex queries without modifying a single line of application code, bringing the performance benefits of Readyset to an even broader range of use cases. What Are Window Functions? Window Functions are one of SQL's most powerful features for analytical queries. They let you perform calculations across rows that are related to the current row, without needing c

Database performance is often the bottleneck in high-traffic web applications. Whether you're serving user dashboards, product catalogs, or personalized content, the same SQL queries get executed repeatedly. Caching sounds like the natural solution. However, traditional caching can be challenging to implement correctly: you need to manually add cache logic to your application (such as Redis), keep cache entries in sync, and address edge cases like stale data. Readyset takes a different approach

Introduction We at Readyset, recently launched the public beta of QueryPilot, an automatic query caching layer designed to make scaling relational databases effortless. QueryPilot analyzes real-time query traffic, identifies high-impact patterns, and transparently caches results, without requiring code changes or database tuning. In an effort to show how easy it would be for applications to take advantage of QueryPilot, we put it to test against one of the most prolific content platforms on t
Tanmay Sinha
Introduction Readyset is designed to serve queries from cached views with sub-millisecond latency. This post focuses on the cold path—cases where a cache miss forces execution against the base tables. In these scenarios, Readyset must evaluate the query from scratch, including materializing intermediate results. The focus here is on straddled joins, where filtering predicates apply to both sides of the join in addition to the ON clause. Example: SELECT u.id, u.name, o.order_id, o.total FROM u
Marcelo AltmannAugust’s here, and we’re kicking it off with a bang. Here’s what’s new at Readyset: 🛫 Introducing Readyset QueryPilot: Zero-Touch Caching for OLTP Workloads We’re excited to announce the public beta for Readyset QueryPilot for MySQL, our smart database scaling solution that automatically caches high-impact OLTP queries. No code changes. No manual tuning. QueryPilot analyzes live traffic in real time, identifies expensive queries, and routes them through Readyset’s high-performance cache. Al
QueryPilot is Readyset’s automatic query caching engine for MySQL. It automatically identifies and caches your most expensive queries at the SQL layer, with no code changes or manual tuning. Today, we're announcing the Public Beta of Readyset QueryPilot, a significant step toward making OLTP workloads, especially AI-generated applications, scale seamlessly. Think of this as the “Look Ma, no hands” moment for database performance. You route traffic once, QueryPilot takes the handlebars, caches s
Gautam GopinadhanHi there, hope you’re keeping cool as summer heats up! Let’s dive into what’s new at Readyset: 💬 Product Updates Readyset Cloud * Improved concurrency management and cache reliability enabling a more predictable and resilient system. Improvements include thread-safe request limiting, enhanced lifecycle tracking, and improved Data Plane REST error handling and observability. * Enhanced key interfaces to improve performance analysis workflows and reduce visual bugs, including: redesigned

Consider the perfect scenario: the database is running on reliable hardware, MySQL has been finely tuned, and queries have been reviewed and optimized. Despite this, sustained business growth inevitably leads to an increase in workload over time. When this happens, even optimized queries can begin to overwhelm the system, not because they are slow, but because they run frequently and consume cumulative resources over time. At this stage, optimizing performance goes beyond analyzing execution pl
Readyset is a database scalability and query caching platform designed to dramatically accelerate query performance without requiring code changes. Based on nearly a decade of research at MIT on database caching and incremental view maintenance, it is built to work seamlessly with PostgreSQL and MySQL. Readyset allows applications to scale instantly by caching query results and incrementally updating them as data changes. The net result is that Readyset supercharges database performance, enabl
A PostgreSQL community member recently sparked a lively discussion on Reddit about database caching strategies. The genuine frustrations expressed in the responses highlighted the need for simpler, more reliable solutions. This article addresses the key concerns raised and suggests how modern SQL caching architectures, such as Readyset, can solve these longstanding problems. Traditional Caching Traditional database caching typically relies on Key-Value (KV) stores such as Redis or Memcached
Hi there, hope you’re enjoying a great start to the summer season! Let’s dive into what’s new at Readyset: 📝 We're Taking Applications for QueryPilot Private Beta We’re now accepting applications for the private beta of QueryPilot, our new smart, single endpoint that finds and fixes slow queries, handles caching in real time, and routes traffic intelligently across replicas; so you can focus on building, not babysitting your database. Interested in the beta? Send a quick note to hello@rea

Every engineer eventually confronts the complexities of scaling applications and systems. At first glance, the solution seems straightforward: add more cores, introduce replicas, or distribute workloads. However, at scale, each decision quickly compounds in complexity, introducing unexpected overhead, rising costs, and increasingly fragile systems. The reality is that effective scaling isn’t solely about adding more resources, but also about strategically reducing redundant computations. Th

Introduction It’s common for DBAs to optimize queries to address bottlenecks and reduce resource contention. However, in production workloads, the most resource-intensive queries aren’t always the longest-running ones. High-frequency queries that execute quickly but are called repeatedly can collectively consume significant resources, increasing overall latency and system load. Identifying these queries requires a more comprehensive analysis than simply inspecting the slow query log or process

In today's digital economy, milliseconds matter — and not in abstract ways. Every additional millisecond of application response time erodes user satisfaction, increases abandonment rates, and compounds operational inefficiency. Research consistently shows that customer patience is measured not in seconds, but in fractions of a second. According to Google's research, 53% of mobile users abandon a site if it takes longer than three seconds to load, and most abandonment decisions happen within th
Wagner BianchiHi there, hope your spring is off to a great start! Here’s what’s new at Readyset: 🎉 Readyset Private on Azure VM (MySQL Edition) You can now deploy Readyset privately on an Azure VM with MySQL and see performance gains from milliseconds to microseconds! Setting up takes just minutes and a few commands, with no replicas, rewrites, or added complexity required. It’s a perfect fit for teams running on Azure and seeking to enhance MySQL performance and scalability while reducing costs. All of

"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
Michael Virga
Scaling relational databases in the cloud often creates a tension between cost and performance. As workloads grow—especially read-heavy ones powering analytics, dashboards, or reports—latency increases and infrastructure bills spike. The default response is usually vertical scaling: increase instance size, add more CPU and memory. While effective up to a point, this approach quickly hits diminishing returns and inflates costs. An alternative is horizontal scaling, traditionally achieved through

The title of this post sets the stage for a compelling discussion, and I’ll start with a direct spoiler: Readyset is about performance. It delivers exceptional query acceleration because it behaves as an intelligent cache—without relying on traditional TTLs, background eviction processes, or complex locking mechanisms. More importantly, it integrates seamlessly with your existing application stack: no changes to application logic are required. From an architectural standpoint, Readyset drastical
Wagner Bianchi
We are excited to announce a strategic technology partnership between Readyset, the leading provider of SQL query caching solutions, and CYBERTEC PostgreSQL International GmbH, the premier PostgreSQL services and support company based in Austria. This collaboration brings together two organizations deeply committed to helping PostgreSQL users achieve new levels of performance, scalability, and operational efficiency. As a technology partner to CYBERTEC, Readyset is proud to support PostgreSQL c
Tanmay SinhaHello and happy Spring! Hope everyone had a great March. Let’s dive into what the Readyset team has been up to. 🎉 AWS Foundational Technical Review Approved We’re thrilled to announce that Readyset has completed and passed the AWS Foundational Technical Review (FTR)! The AWS FTR ensures that AWS partner products meet rigorous security, reliability, and operational excellence requirements as defined by the AWS Well-Architected framework. This milestone reflects our commitment to building a
We’re excited to announce a major milestone: Readyset Cloud has officially achieved AWS Foundational Technical Review (FTR) approval! This certification validates that Readyset meets AWS’s high standards for cloud-native security, reliability, and operational excellence—and it reaffirms our commitment to AWS as the preferred platform for customers scaling their PostgreSQL and MySQL databases. This approval signals our deep alignment with AWS best practices and underscores our focus on helping o
Tanmay SinhaIn our blog post on Optimizing SQL Pagination in Postgres, we explained how to optimize SQL pagination for Postgres. As a counterpart, we’ve decided to write one for MySQL pagination. Like PostgreSQL, MySQL offers several ways to handle pagination, but some are far more efficient than others. Let's break down the SQL Pagination options, talk about why LIMIT and OFFSET can be a problem, and look at smarter ways to paginate large datasets efficiently. The Classic SQL Pagination Approach: LIMIT
PostgreSQL is one of the most potent relational databases, but performance can become a bottleneck as queries become complex. One of the most effective ways to reduce query latency without modifying application logic is caching, and Readyset provides a seamless solution. Readyset sits between your application and PostgreSQL, automatically caching queries and speeding up their response times considerably. In this guide, we’ll walk through: Installing Readyset on Ubuntu 24.04 using a .deb packa
Wagner BianchiOptimizing MySQL and PostgreSQL performance is crucial for modern applications, especially those with read-heavy workloads. Readyset is a drop-in SQL caching engine that sits between your application and the database. It automatically caches query results to improve response times without requiring application changes. In this post, we'll cover: Installing Readyset on Ubuntu 24.04 using a .deb package Configuring Readyset to connect to an upstream MySQL database Running queries and caching r
Wagner Bianchi👋 Hello – hope everyone had a great February! Let’s catch up on what’s new at Readyset. 🚨 Grupo Ótima Digital Cuts Database Load and Scales MySQL Infrastructure with Readyset Grupo Ótima Digital, a leading messaging solutions provider in Brazil, reduced its MySQL database load by over 30% overnight with Readyset. Head to our blog to discover how Readyset helped Grupo Ótima Digital overcome scalability challenges and turbocharge query performance with zero code changes and seamless integr
👋 Hello – it’s our first product update of 2025, so let’s kick the year off with some big updates. Readyset 🤝 PerformanceDB We’re elated to announce our new partnership with PerformanceDB with the goal of improving MySQL database scaling for businesses in Brazil! By pairing Readyset’s advanced query caching technology with PerformanceDB’s deep expertise in MySQL database management, we’re offering businesses in Brazil a seamless, cost-effective way to scale their databases. With localized
At Readyset, our mission has always been to empower businesses by providing innovative database scaling solutions that help organizations maximize the performance of their existing Postgres and MySQL infrastructures. Today, we are thrilled to announce a transformative partnership with PerformanceDB, a leading database support and service provider, to better serve our customers across Brazil. This partnership represents a significant step forward in delivering top-tier database optimization solu
Tanmay SinhaModern applications demand scalability to support growing user bases, real-time responsiveness, and large data volumes. But as applications grow, vertical scaling by adding more compute resources has an upper limit. Once those limits are hit, you’ll need to figure out horizontal scaling by adding more servers into your environment. As most applications are typically read-heavy, the first step to scaling out your database is by adding read replicas to handle the additional load placed on them.
Brian Morrison IITracing memory allocations is critical when debugging performance or memory-related issues in high-performance applications. However, Rust still lacks a good toolset to do so and often some techniques require code changes such as changing default global allocator. In this article we will explore how we were able to track large memory allocations we were seeing on Readyset, such as the one in the above graph by using bpftrace. BPFtrace is a high-level tracing language for Linux, built on the Be
Marcelo Altmann👋 Hello 2025 – Hope you’re settling into the new year and had a joyful holiday season! Let's dive into what's new at Readyset. Readyset MySQL Interactive Demo In November, we launched our interactive demo for Postgres, and we're excited to announce that the demo is now live for MySQL as well! With a pre-configured setup—including a client, Readyset cache, and demo database—seeing Readyset in action is easier than ever. Just create a Readyset Cloud account, follow the easy step-by-step gu
👋 Hello December! Hope everyone had a great November and for those who celebrated, a wonderful Thanksgiving. Before we dive in, a quick note: our VP of Product, Tanmay Sinha, and I are currently at AWS re:Invent and would love to connect with you! If you’re attending and want to discuss database scaling, click here to set up a meeting. Now, here’s what’s new at Readyset. New Interactive Readyset Cloud Demo We’re excited to share that Readyset Cloud now includes an interactive demo, maki
Scaling databases is no small task, and in the rush to find fast, affordable solutions, teams often overlook a key technique: query caching. By intelligently caching database queries, we’re sidestepping many of the typical challenges and costs that come with sharding, complex materialized views and resource-intensive indexes. Yet, it’s surprising how often query caching is dismissed as a solution. Let’s dive into why it might be the most cost-effective way to achieve the scale you’re after. Ho
Gautam GopinadhanYou've crafted the ideal SQL query. It's beautiful. A work of art. Then, it takes seconds to execute and hangs your entire application. What went wrong? You need a way to look under the hood of SQL and understand the inner workings of your query. “Under the hood” is precisely what the EXPLAIN and EXPLAIN ANALYZE commands were built for–to guide you through the labyrinth of query optimization. These offer a glimpse into the database optimizer, revealing how your query is executed and identifying
Marcelo Altmann👋 Hope everyone had a great October and enjoyed spooky season! Here’s a look at what’s new at Readyset. 🚨 ClickFunnels Reduces Database Workload by 85% with Readyset ClickFunnels, a leading marketing and lead generation platform, reduced its database workload by over 85% in just a few days with Readyset! We're thrilled to highlight our implementation with ClickFunnels in our newest case study. Head to our blog to learn how ClickFunnels uses Readyset to manage its growing database demands
Overview MySQL 5.7 has reached EOL in October 2023 forcing users to migrate to MySQL 8.0. Migrating from MySQL 5.7 to MySQL 8.0 offers significant performance improvements and new features, but the removal of the Query Cache in MySQL 8.0 can pose challenges and performance hits. Readyset provides a solution to maintain and improve query performance by acting as an external query cache with automatic cache updates. This white paper outlines a migration strategy that integrates Readyset into the
Marcelo Altmann👋 Happy fall! September has been a busy month for the Readyset team, and we’re excited to share some of our new releases. Let’s check out what’s new at Readyset! Product Updates Readyset Cloud 🐬 MySQL Support on Readyset Cloud Readyset Cloud now supports MySQL! This means MySQL users can experience up to 100x faster queries and up to 70% reductions in database workloads, saving thousands every month. Readyset seamlessly integrates with AWS RDS and other self-hosted or managed MySQL inst

Readyset is thrilled to announce the availability of MySQL database support in Readyset Cloud! This marks a significant milestone for MySQL users who have long sought an efficient way to speed up their database queries while reducing operational costs. Boost MySQL Performance with Readyset Cloud Readyset Cloud provides a future-proof solution for MySQL users looking to boost performance without being constrained by the lack of native caching and expensive alternatives. By offloading read quer
Tanmay SinhaWe hope you're enjoying the start of September. Let's check out what's new at Readyset! Product Updates Readyset Cloud * BYO-VPC is live! Customers can now deploy Readyset and maintain full control over their cloud environment. Check out this short video walkthrough on how to set up BYO-VPC in 3 simple steps and read more here. Readyset Core * Added a new `--cdc-db-url` parameter, allowing users to specify a separate database URL for the CDC user, providing more control and security ov
Joins are a concept in relational databases, allowing the combination of data from two or more tables. Joins establish a relationship between two tables using a common key, which is used to lookup data from one table to another. There are different types of joins and different algorithms that can be used to retrieve the data. In this article we will be focusing on discussing the differences between each algorithm. Nested Loop Joins A Nested Loop Join algorithm is a straightforward method for
Marcelo AltmannReadyset is excited to announce the support for its revolutionary database scaling and query caching platform, Readyset Cloud, for Supabase Database, a hosted PostgreSQL database trusted by millions of developers. As your application grows, so does the load on your database. Increased traffic, complex queries, and high data volumes can lead to slow query performance, frustrating users and impacting your business. Traditional caching solutions and read replicas can help but only up to a ce
Tanmay SinhaAs we dive into August, it’s time to take a look at what the Readyset team was up to in July! Readyset BYO-VPC Is Live Readyset BYO-VPC has been our most requested feature, and we’re thrilled to announce that it is now live! With BYO-VPC, customers can use their own VPCs on Amazon AWS to ensure that their data remains within their own infrastructure – enhancing data privacy and security. If you’re interested in learning more about Readyset BYO-VPC or are ready to get started today, book tim
We are thrilled to announce that Readyset Cloud is now available on AWS Marketplace! This marks a significant milestone in our journey to make our product more accessible and user-friendly for our customers. Readyset Cloud supports out-of-the-box integration with AWS RDS for PostgreSQL, Aurora for PostgreSQL and even self-hosted PostgreSQL distributions. Unlike other caching solutions, Readyset Cloud as a read replica keeps the cache in sync with your database automatically and is wire-compat
Hello July! With another month over, it’s time for an update on what we shipped at Readyset in June. Let’s take a look at what’s changed: Readyset at AWS Summit in NYC Our VP of Product, Tanmay, is in New York City this week for the AWS Summit on July 10th, 2024. This will be an action packed day themed around generative AI and infrastructure modernization. If you’re attending the summit and would like to connect, discuss database trends, or learn more about Readyset, please respond to this
May is over, the days are getting hotter, and it’s time for an update on what we’ve been shipping at Readyset! Let’s take a look at what’s changed since April: Readyset Query Support is Expanding Readyset has partnered with some of the largest MySQL and Postgres shops in the world to continue expanding our query support. We want to continue partnering with users to ensure Readyset is compatible with the queries you want to cache. If you’ve been testing or considering using Readyset, meet
Introduction MySQL 8.0.20 introduced a binary log transaction compression feature designed to save storage space and reduce network bandwidth usage by applying compression to each transaction. This feature can be enabled dynamically without restarting the server by setting the binlog_transaction_compression system variable to ON, as it is OFF by default. Additionally, the compression level of the zstd algorithm can be adjusted using the binlog_transaction_compression_level_zstd variable. By def
Marcelo AltmannReal-world applications face performance challenges with growing data and user traffic. Caching mitigates these challenges by storing frequently accessed data, reducing database fetches, improving response times, and enhancing application scalability, reliability, and user experience. Readyset is a caching engine for Postgres and MySQL databases, requiring minimal adjustments to existing setups. Its wire-compatible design means that the only modification necessary is to adjust the connection st
Rishi Raj JainMySQL 8.0 has been known for its innovative pace, introducing new breaking changes in minor releases within the 8.0 series, which has been a great debate among the MySQL community and a long ask to have a more stable release cadence within the same minor series. Oracle has listened to MySQL users and has announced a new release model, where it introduces the concept of LTS releases and Innovate releases. On the 30th of April, the first Long Term Support release was announced. This release rece
Marcelo AltmannBack in October 2023, MySQL 5.7 reached end-of-life. With it went support for some of the earlier functionality of MySQL. No more updates, no more security patches, and, in some cases, no more customer support (or, rather, extended support continues, but at a premium). One of the features on the chopping block was MySQL Query Cache, which has now been completely removed in the current stable major release, MySQL 8.0. Many engineers and DBAs are happy to see the back Query Cache. But not everyo
Marcelo AltmannApril is officially over and it’s time for an update on what we’ve been shipping at Readyset! Let’s take a look at what’s changed since March: Partner with Readyset Readyset is looking for design partners to build out additional MySQL and PostgreSQL functionality in Readyset Cloud. If you’ve been considering using Readyset in production, meet with our engineering team to discuss your use case and have direct influence on our compatibility roadmap. Spots are limited. New Blogs Check out ou
SQL pagination is a technique to retrieve a subset of records from a Postgres table or result set. It allows you to divide large datasets into smaller, manageable chunks called "pages" and retrieve them one page at a time. Understanding Pagination in Postgres Pagination is commonly used in applications that display data in a paginated format, such as search results, product listings, or user records. It helps improve performance and user experience by loading and displaying only a portion o
When you first spin up your app, the emphasis is on getting started and getting data to your clients. But when you don’t have throughput, you are also not going to have enough concurrency to unveil bad queries. But then you have success. And success means data. More users, more interactions, more everything. Suddenly, queries that performed fine are struggling under the load, hurting performance and scalability. This is all going to mean a far worse user experience when much higher costs becaus
Marcelo AltmannIn our previous blog post we announced Readyset version stable-240328 comes with the ability to integrate with ProxySQL. This version inspired the creation of a dedicated scheduler for integrating Readyset with ProxySQL, bringing the ability to automatic inspect your workload and cache problematic queries: 0:00 /3:32 1× Use Scheduler to Integrate Readyset and ProxySQL To easily integrate Readyset and ProxySQL, we have created a scheduler to automatic
Marcelo AltmannProxySQL is a high-performance, high-availability proxy for MySQL, serving as an intermediary between MySQL clients and servers to optimize and manage database traffic. It provides advanced query routing, directing queries to the most appropriate database server based on predefined rules, such as the query type or server load, thus enhancing performance and spreading the load evenly across servers. Open and closing connections in MySQL means creating and deleting new OS threads, which under the
Marcelo AltmannGet Started With Readyset Cloud Readyset Cloud is a SQL caching platform that helps you build performant, real-time applications without any code changes or switching databases. Sign up to start caching your queries today, or schedule a demo to explore how Readyset Cloud fits into your stack. Readyset @ QCon London Are you heading to QCon London? Alana Marzoev, founder and CEO of Readyset, will be speaking on Tuesday, April 9th at 10:35 AM BST. You can find more info on her talk, Powering
Database maintenance is a crucial ingredient for sustained performance and data integrity. For platform engineers, automating routine tasks within a PostgreSQL environment ensures both reliability and relieves team members from repetitive manual work. Here's a quick rundown of effective approaches: Fine-Tuning Autovacuum PostgreSQL's built-in autovacuum daemon automates essential VACUUM and ANALYZE operations. To get the most out of it: Verifying Autovacuum Enablement Ensure autovacuum
Marcelo AltmannReadyset Cloud Now Available for AWS Postgres Readyset Cloud is now available for AWS Postgres users. When using Readyset Cloud, you can expect a drop-in integration and support for caching complex queries and automatically keeping the result sets up-to-date. To get started, create an account here. Interactive Cloud Demo If you want to test out Readyset Cloud without connecting to your own database, you can use our demo database. Try it out here. 0:00 /0:16 1×
Laravel is an excellent framework for those who want to use PHP. It pairs well with other languages, offers clean code, and includes features for a full-stack application out-of-the-box. One of those features is caching. Laravel includes an elegant, comprehensive caching system designed to be highly flexible, allowing developers to choose from various caching drivers and strategies, tailoring the caching solution to fit their applications' specific needs and architecture. This adaptability e
Imagine you're running a popular e-commerce online bookstore that offers a vast collection of titles and authors to a growing user base. However, you've noticed a troubling trend over the past few months: the website is gradually slowing down, especially during peak hours when users browse various book categories. After an initial investigation, you find that the cause of the slowdown isn't an increase in user traffic or a lack of server resources. Instead, it's rooted in the very foundation of
Readyset Cloud Available for AWS Postgres Readyset Cloud is a query caching platform that helps development teams improve the performance and scalability of their applications without code rewrites, query optimization, or infrastructure overhauls. Now, it's available for all AWS Postgres users. You can expect a drop-in integration, support for automatically caching complex queries and keeping the result sets up-to-date. To get started, create an account here. Product Updates Quickstart
Readyset Cloud is a query caching platform that helps development teams improve the performance and scalability of their applications without code rewrites, query optimization, or infrastructure overhauls. This blog walks through the overarching process for how to set up Readyset Cloud as a caching layer for a data-driven application. It’s intended as a high-level overview– for step-by-step instructions, see the official Readyset Cloud onboarding documentation. Step 1: Create a Readyset c
Caching is a Goldilocks problem. Caching too much leads to stale data, memory bloat, and a lot of cache management. Caching too little leads to longer latencies, higher database load, and the need to provision more and more storage. The aim is to cache just right, optimize cache performance, minimize database load, and enhance overall system efficiency. This is a lot easier said than done. How do you know what to cache and when? Modern databases help you understand the usage patterns of your
Most read articles
Explore the blog posts our readers keep coming back to the most.
Modern applications demand instant performance, even under unpredictable load. Readyset helps you eliminate slow queries, stabilize latency, and scale confidently.
Revolutionize your database performance with Readyset
Serve requests at sub-millisecond latencies with the modern database scaling and query caching system for MySQL and PostgreSQL.
Join our newsletter
Stay updated with the latest news, insights, and developments from Readyset — straight to your inbox.