TideSQL 5.0.0: LSM storage engine for MariaDB based on TidesDB 10

MariaDB Foundation published on 23 September 2026 on its blog an update on TideSQL, the pluggable storage engine for MariaDB based on TidesDB. Version 5.0.0 arrives just a few months after the initial experiments reported by the author and is based on TidesDB 10, as stated in the official post on mariadb.org.

TidesDB is an embeddable and transactional C library with key-value semantics, based on LSM-tree (Log-Structured Merge-tree): writes are absorbed in memory and in the write-ahead log, then flushed to sorted files with background compaction. TideSQL is the layer that exposes this architecture as a standard SQL storage engine within MariaDB, using ENGINE=TIDESDB syntax on CREATE TABLE statements.

What's new in version 5

Compared to the early trials, TideSQL 5 adds MVCC transactions, primary and secondary indices, foreign keys, auto-increment, generated columns, savepoints, XA transactions, partitioning and online DDL. On top of this come compression, TTL, online backup and encryption at rest. The blog also highlights support for full-text indices with BM25, vector indices for approximate nearest-neighbour searches and spatial indices, all usable within the same SQL syntax as MariaDB.

For installation, TideSQL can now be compiled and packaged with MariaDB Foundry, which produces RPM, DEB and tar.gz packages without needing to recompile the entire MariaDB Server source tree.

Numbers from vendor benchmarks

According to a sysbench test published by the TidesDB team and cited in the blog, on MariaDB 13.1 with 16 tables of one million rows each (approximately 3 GB of data) and workload at 1, 8 and 16 threads, with constrained cache settings (InnoDB buffer pool 128 MB, TideSQL block cache and memtable at 256 MB each), TideSQL leads in 9 out of 10 workloads at 16 threads, particularly on secondary index updates.

With cache increased to 4 GB, the picture changes: InnoDB is reported as approximately 2.9 times faster on point selects according to the vendor, whilst TideSQL maintains the lead on write-heavy workloads (updates, deletes, inserts). With full durability (innodb_flush_log_at_trx_commit=1 for InnoDB and FULL synchronisation for TideSQL), the differences narrow, but TideSQL retains the advantage on write-heavy workloads, according to the vendor's figures.

An operational detail to be aware of

TideSQL uses optimistic conflict validation on certain transactional workloads: under contention, transactions may be retried at commit. The blog notes that the conflict can reach the client as MariaDB error 1180 (ER_ERROR_DURING_COMMIT) instead of the more expected 1213 (ER_LOCK_DEADLOCK). Applications with retry logic that only triggers on error 1213 should take note before adopting the engine in production.

TideSQL also supports standard MariaDB replication and Galera integration via the wsrep interface, with participation in write-set certification at the engine level.

For further details: the original post at mariadb.org/tidesql-5-and-mariadb-the-tides-are-moving-fast/.