MariaDB RocksDB: MyRocks Engine for Write-Heavy Workloads (2026)

MyRocks is a storage engine for MariaDB that uses Facebook’s RocksDB library as its foundation, making it a compelling choice for write-heavy workloads.

Let’s see it in action. Imagine a simple users table:

CREATE TABLE users (
    id INT AUTO_INCREMENT PRIMARY KEY,
    username VARCHAR(255) NOT NULL,
    email VARCHAR(255) UNIQUE,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
) ENGINE=ROCKSDB;

Now, let’s insert a million users as fast as possible:

INSERT INTO users (username, email) VALUES
('user_1', 'user_1@example.com'),
('user_2', 'user_2@example.com'),
-- ... up to user_1000000

With MyRocks, this bulk insert operation is significantly faster and more efficient than with traditional engines like InnoDB. Why? Because MyRocks is designed from the ground up for high write throughput.

The core of MyRocks is RocksDB, a persistent key-value store. Unlike InnoDB, which uses a B+ tree structure and writes data to a single, large data file (or multiple files for tablespaces), MyRocks employs a Log-Structured Merge-Tree (LSM-tree) architecture.

Here’s how the LSM-tree works in MyRocks:

1. Memtable: Writes initially go into an in-memory structure called the memtable. This is a fast, volatile buffer.
2. Immutable Memtable: Once the memtable reaches a certain size, it’s "frozen" into an immutable memtable.
3. SST Files (Sorted String Tables): The immutable memtable is then flushed to disk as an SST file. These SST files are immutable and sorted.
4. Compaction: As more SST files are generated, RocksDB performs a background "compaction" process. Compaction merges multiple SST files into new, larger SST files, removing duplicate or obsolete data in the process. This is crucial for managing disk space and read performance.

This LSM-tree approach has several key advantages for write-heavy workloads:

• Write Amplification: MyRocks significantly reduces write amplification. In InnoDB, updates and deletes can involve reading a page, modifying it, and writing it back, potentially multiple times. MyRocks, by appending data to memtables and then flushing to SST files, has a more sequential write pattern. Compaction is where the "write" for updates/deletes happens, but it’s done in larger, more efficient batches.
• Space Amplification: While LSM-trees can sometimes have higher space amplification due to multiple versions of data existing before compaction, MyRocks is optimized to mitigate this. It uses techniques like block-based compression and efficient garbage collection during compaction.
• Read Amplification: Reads in an LSM-tree can be more complex as data might be spread across multiple SST files. RocksDB addresses this by organizing SST files into "levels" and using Bloom filters to quickly check if a key might exist in a particular file. Compaction also helps consolidate data, reducing the number of files a read needs to consult.

MyRocks also offers excellent compression capabilities. It supports various compression algorithms (like zlib, lz4, zstd) that can be configured per column family, allowing fine-grained control over storage footprint and CPU usage.

The primary configuration parameters that influence MyRocks behavior are found within the my.cnf or my.ini file, often under a [rocksdb] or [mysqld] section. Key options include:

• rocksdb_block_cache_size: This is the size of the block cache, which caches uncompressed data blocks from SST files in memory. A larger cache can significantly improve read performance by reducing disk I/O. For example, rocksdb_block_cache_size = 1073741824 (1GB).
• rocksdb_memtable_size: The maximum size of a single memtable before it’s flushed. For example, rocksdb_memtable_size = 268435456 (256MB).
• rocksdb_max_subcompactions: This controls how many sub-compactions can run in parallel. Increasing this can speed up compaction on multi-core systems. For example, rocksdb_max_subcompactions = 4.
• rocksdb_compression_type: The compression algorithm to use. zstd is often a good balance of compression ratio and speed. For example, rocksdb_compression_type = 'zstd'.

MyRocks is particularly effective for use cases like:

• Time-series data: High ingest rates, often with older data becoming irrelevant.
• IoT data: Similar to time-series, massive amounts of incoming sensor data.
• Caching layers: Where writes are frequent and reads need to be fast.
• User activity logging: Tracking user interactions that generate a high volume of events.

When you’re tuning MyRocks, remember that the interplay between rocksdb_block_cache_size and rocksdb_memtable_size is critical. A larger block cache helps with reads, while a larger memtable allows more writes to be buffered before hitting disk, potentially improving write throughput but also increasing memory usage and the potential for larger flushes.

The next hurdle you’ll likely encounter is managing the lifecycle of your data, particularly when dealing with time-series or event data where old records can be purged.