Key takeaways
- Bypasses legacy bottlenecks without hardware upgrades: MariaDB 12.3.2 routes binary log writes through InnoDB’s faster internal I/O engine, unlocking major throughput gains on your existing infrastructure.
- Delivers up to 50% higher overall transaction speed: Enabling the new InnoDB-accelerated logging feature dramatically scales database performance up to 1.5x over previous server versions.
- Boosts speed while keeping strict data safety: Even under full ACID durability settings, the new architecture provides an immediate 17% performance increase with zero compromise on data security.
What Is the MariaDB Binary Log Bottleneck and How Does InnoDB-Based Logging Solve It?
In modern high-performance database infrastructure, the binary log (Binlog) is both a lifesaver and a well-known architectural bottleneck. While critical for replication, point-in-time recovery, and data auditing, writing sequentially to transactional logs and simultaneously managing the global MariaDB Binlog introduces massive locking and synchronization overhead.
With the release of MariaDB Community Server 12.3.2, a new feature has been introduced: InnoDB-Based Binary Log.
Despite the name, this doesn’t mean binlog events are stored as InnoDB table rows — the binlog remains a distinct set of files on disk (with a new .ibb extension), but writes now go through InnoDB’s internal I/O and redo-log machinery instead of the legacy binlog file code path, resulting in “InnoDB-Accelerated Binary Logging.”
This post analyzes benchmark data comparing traditional binary logging in MariaDB 11.8.8 and 12.3.2 against the newly introduced InnoDB-Based Binary Log feature across various innodb_flush_log_at_trx_commit settings.
How Was the MariaDB InnoDB-Based Binary Log Benchmarked?
The performance benchmarking was done using the HammerDB TPROC-C workload profile — an open-source industry standard derived from the TPC-C specification for online transaction processing (OLTP) running on an AMD EPYC 9454P 48-Core Processor. The core metric tracked across all test cycles is NOPM (New Order Per Minute).
The primary benchmarking variable focused on the storage engine’s strictness regarding durability. Specifically, performance isolated the impact of the innodb_flush_log_at_trx_commit configuration parameter across its four valid topologies (0, 1, 2, and 3). This variable specifies how frequently transactions are flushed and synced to disk storage.
What Performance Gains Does InnoDB-Based Binary Logging Deliver Across Flush Configurations?
Across all tested configurations, the InnoDB-Based Binary Log in MariaDB 12.3.2 shows gains:
- Max Performance (
innodb_flush_log_at_trx_commit = 0): The engine handles a massive 878,535 NOPM (New Orders Per Minute). This represents a substantial 1.40X gain compared to standard 12.3.2 Binlog, and a 1.50X gain over the MariaDB 11.8.8 baseline. - Strict ACID Compliance (
innodb_flush_log_at_trx_commit = 1): Where the log buffer is flushed and synced to disk at every transaction commit, the InnoDB-Based Binary Log feature delivers a 1.17X gain, achieving 711,602 NOPM. This provides a major performance improvement under full transaction durability. - Balanced Durability (
innodb_flush_log_at_trx_commit = 2and3): Across these configurations, InnoDB-Based Binary Log delivers scaling ranging from 1.22X to 1.24X when measured against MariaDB 11.8.8.
Performance Graph
Transaction Count
Why Should You Enable InnoDB-Based Binary Logging in MariaDB 12.3.2?
Upgrading from MariaDB 11.8.8 to 12.3.2 using standard binary logging yields only incremental improvements, ranging from a 1.00X to 1.07X gain.
By contrast, enabling the InnoDB-Based Binary Log feature unlocks an entirely new tier of raw horizontal scalability without requiring any hardware modifications, achieving a significant performance gain of up to 1.5X over MariaDB 11.8.8.
Frequently Asked Questions
The InnoDB-Based Binary Log is an architectural feature introduced in MariaDB Community Server 12.3.2 designed to eliminate replication logging bottlenecks. Rather than storing binary log events as standard InnoDB table rows, the feature retains distinct binary log files on disk using a new .ibb file extension. Transaction writes are routed directly through InnoDB's internal I/O and redo-log machinery instead of the legacy binary log code path. This process, known as InnoDB-Accelerated Binary Logging, significantly reduces global locking and synchronization overhead.
Under strict ACID compliance (innodb_flush_log_at_trx_commit = 1), where the log buffer is flushed and synced to disk at every transaction commit, traditional binary logging incurs heavy I/O overhead. With InnoDB-Based Binary Log enabled, MariaDB 12.3.2 achieves 711,602 New Orders Per Minute (NOPM) on HammerDB TPROC-C benchmarks. This represents a 1.17X performance gain over standard logging while maintaining full transaction durability guarantees.
The maximum throughput recorded during testing reached a 1.50X performance improvement over the MariaDB 11.8.8 baseline configuration. This peak was measured under innodb_flush_log_at_trx_commit = 0, where MariaDB 12.3.2 processed 878,535 New Orders Per Minute (NOPM). Compared directly to standard binary logging in version 12.3.2, this configuration yields a 1.40X performance increase.
Upgrading from MariaDB 11.8.8 to 12.3.2 using legacy binary logging delivers modest gains ranging between 1.00X and 1.07X. Enabling the InnoDB-Based Binary Log feature unlocks scaling up to 1.50X over MariaDB 11.8.8 without hardware changes. Across intermediate flush settings (innodb_flush_log_at_trx_commit set to 2 or 3), throughput scales consistently between 1.22X and 1.24X.
Benchmarking was executed using the HammerDB TPROC-C workload profile, an open-source industry standard derived from the TPC-C specification for Online Transaction Processing (OLTP). The test hardware environment utilized an AMD EPYC 9454P 48-Core Processor. The core benchmark metric evaluated across test cycles was New Orders Per Minute (NOPM) across four flush topology configurations.
Yes, when InnoDB-Based Binary Logging is enabled, binary log events are written to files using a new .ibb file extension. While these files leverage InnoDB's internal I/O subsystem and redo-log machinery for optimized flushing, they remain distinct log files on disk rather than standard database table rows. This ensures compatibility with binary log auditing and replication mechanisms while bypassing legacy locking bottlenecks.
