TideSQL 5.0.0: lo storage engine LSM per MariaDB basato su TidesDB 10

MariaDB Foundation ha pubblicato il 23 settembre 2026 sul proprio blog un aggiornamento su TideSQL, lo storage engine pluggable per MariaDB basato su TidesDB. La versione 5.0.0 arriva pochi mesi dopo i primi esperimenti riportati dall'autore e si basa su TidesDB 10, come riporta il post ufficiale su mariadb.org.

TidesDB è una libreria C embeddable e transazionale a chiave-valore, basata su LSM-tree (Log-Structured Merge-tree): le scritture vengono assorbite in memoria e nel write-ahead log, poi riversate su file ordinati con compattazione in background. TideSQL è il livello che espone questa architettura come storage engine SQL standard dentro MariaDB, con sintassi ENGINE=TIDESDB sulle CREATE TABLE.

Cosa c'è di nuovo nella versione 5

Rispetto alle prime prove, TideSQL 5 aggiunge transazioni MVCC, indici primari e secondari, foreign key, auto-increment, colonne generate, savepoint, transazioni XA, partizionamento e online DDL. A questo si aggiungono compressione, TTL, backup online e cifratura dei dati a riposo. Il blog segnala anche supporto a indici full-text con BM25, indici vettoriali per ricerche approximate nearest-neighbor e indici spaziali, tutti utilizzabili nella stessa sintassi SQL di MariaDB.

Per l'installazione, TideSQL può ora essere compilato e impacchettato con MariaDB Foundry, che produce pacchetti RPM, DEB e tar.gz senza dover ricompilare l'intero albero sorgente di MariaDB Server.

I numeri dei benchmark dichiarati dal produttore

Secondo un test sysbench pubblicato dal team TidesDB e citato nel blog, su MariaDB 13.1 con 16 tabelle da un milione di righe ciascuna (circa 3 GB di dati) e workload a 1, 8 e 16 thread, con cache iniziali ridotte (InnoDB buffer pool 128MB, TideSQL block cache e memtable a 256MB ciascuno) TideSQL risulta avanti in 9 workload su 10 a 16 thread, soprattutto sugli aggiornamenti di indici secondari.

Con cache portate a 4GB, il quadro cambia: InnoDB risulta circa 2,9 volte più veloce sui point select dichiarati dal produttore, mentre TideSQL resta avanti sui carichi di scrittura (update, delete, insert). Con durabilità piena (innodb_flush_log_at_trx_commit=1 per InnoDB e sincronizzazione FULL per TideSQL) le differenze si riducono, ma TideSQL mantiene il vantaggio sui workload write-heavy, sempre secondo i dati dichiarati dal produttore.

Un dettaglio operativo da conoscere

TideSQL usa validazione ottimistica dei conflitti su alcuni workload transazionali: sotto contesa, le transazioni possono essere ritentate al commit. Il blog segnala che il conflitto può arrivare al client come errore MariaDB 1180 (ER_ERROR_DURING_COMMIT) invece del più atteso 1213 (ER_LOCK_DEADLOCK). Chi ha logica applicativa che ritenta solo sull'errore 1213 deve tenerne conto prima di adottare il motore in produzione.

TideSQL supporta anche replicazione MariaDB standard e integrazione con Galera tramite interfaccia wsrep, con partecipazione alla certificazione dei write-set a livello di motore.

Per approfondire: il post originale su mariadb.org/tidesql-5-and-mariadb-the-tides-are-moving-fast/.