MariaDBintermediate

MariaDB Storage Engines

When any engine other than InnoDB is the right choice, and the operational cost of mixing engines in one server.

2 min readIntermediateUpdated 31 Jul 2026Edit this page

MariaDB ships several storage engines. In practice InnoDB is the answer for transactional data, and the others are narrow tools.

Engine	Transactions	Crash safe	Reasonable use
InnoDB	Yes	Yes	Everything transactional — the default
Aria	No	Yes (with page cache)	Internal temporary tables; some read-heavy tables
MyRocks	Yes	Yes	Very write-heavy workloads where space amplification matters
ColumnStore	No	Yes	Analytical queries over large fact tables
Spider	Passes through	Depends on backend	Sharding across remote MariaDB servers
MyISAM	No	No	Legacy only
MEMORY	No	No	Small, rebuildable lookup tables

InnoDB

The default and correct choice for application data: row-level locking, MVCC, crash recovery and foreign keys. Everything in InnoDB Architecture applies.

Aria

MariaDB's crash-safe successor to MyISAM. It is used internally for temporary tables and system tables. It is not transactional, so it is not suitable for application data that must be consistent after a crash mid-write.

MyRocks

An LSM-tree engine built on RocksDB. Compared with InnoDB it typically writes less data per logical write and stores data more compactly, at the cost of read amplification and different tuning. It suits sustained write-heavy workloads where storage cost dominates. See RocksDB for the underlying behaviour.

ColumnStore

A columnar engine for analytics inside MariaDB. It removes the need for a separate analytical system in modest deployments, but its operational model, resource profile and query characteristics are quite different from InnoDB's. Evaluate it against a dedicated column store such as ClickHouse before adopting it for a large workload.

Spider

Shards tables across remote MariaDB servers, presenting them as one table. It moves the sharding problem into the database layer, but all the constraints in Sharding still apply — cross-shard joins, transactions and uniqueness remain hard.

MyISAM has no crash recovery

MyISAM tables can be silently corrupted by a crash or power loss, and repair is a manual, potentially lossy operation. It also has table-level locking, so one write blocks all readers. Convert remaining MyISAM tables to InnoDB:

SELECT table_schema, table_name, engine
FROM information_schema.tables
WHERE engine NOT IN ('InnoDB') AND table_schema NOT IN ('mysql','information_schema','performance_schema');
 
ALTER TABLE legacy_table ENGINE=InnoDB;

The ALTER rewrites the table — plan for the duration and the lock on a large one.

Mixing engines

A transaction spanning an InnoDB table and a non-transactional table is not atomic: the InnoDB part rolls back, the other does not. Galera additionally replicates only InnoDB reliably. Keep application data on one transactional engine and treat exceptions as deliberate, documented decisions.