Marcelo Altmann
Marcelo works as a Senior Software Engineer @ Readyset.
Marcelo Altmann
Marcelo works as a Senior Software Engineer @ Readyset.
Articles by Marcelo Altmann (24)
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
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 Altmann
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 Altmann
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
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 Altmann
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 Altmann
Tracing 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 AltmannYou'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 AltmannOverview 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 AltmannJoins 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 AltmannIntroduction 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 AltmannMySQL 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 AltmannWhen 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 AltmannDatabase 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 AltmannModern 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.