MariaDB

How InnoDB stores rows

A row in InnoDB lives on a 16 KiB page inside a tablespace (usually one file per table, configurable). Each row carries a 6-byte DB_TRX_ID and a 7-byte DB_ROLL_PTR. The roll pointer is the address of the undo log record that can reconstruct the previous version.

When a transaction updates a row, InnoDB writes a new row version in the clustered-index B-tree (which is the table) and inserts an undo record. Other transactions that started before the commit read the undo chain to find the version visible at their snapshot.

The query path

MariaDB ships a cost-based optimizer borrowed and extended from MySQL. SQL enters the parser, becomes a parse tree, then a resolved query block, then a plan. The optimizer applies join reordering, subquery unnesting, and condition pushdown before handing the plan to the executor.

The executor pulls rows through a Volcano-style iterator API. The same operator interface serves every storage engine, which is what makes the pluggable-engine model work.

              CREATE TABLE events (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  payload JSON,
  created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
  INDEX (created_at)
) ENGINE=InnoDB ROW_FORMAT=DYNAMIC;
            

ColumnStore for analytics

ColumnStore is a separate engine that stores each column in its own file and skips irrelevant columns at read time. It runs across multiple servers and is the MariaDB answer to ClickHouse / Snowflake. You load data into a ColumnStore table, query it with the same SQL, and get column-pruned scans served by parallel workers.