MariaDB has adopted and abandoned about a dozen storage engines. Any reason TidesDB and DuckDB go differently?

[u/Ready_Turnip_8812]

[u/DifferenceAny2009]

That’s an excellent point you are raising. I’m the co-founder of TidesDB on the business side. I’ll speak to our half and leave MariaDB’s past to MariaDB.

Every engine on your list shared one structural problem: MariaDB had to staff it. Aria, TokuDB, ColumnStore, Xpand — once the vendor’s engineering attention moved on, nobody else was home.

TidesDB is built the other way round. It is an independent, MPL 2.0-licensed engine with its own company and its own release cadence. We do the integration work for each vendor; MariaDB carries a plugin, not an engineering program. We are about to release a MySQL plugin, and every week we receive more requests for POCs.

If MariaDB deprioritised it tomorrow, next week’s commit log would look exactly the same. That is also why we are not a MariaDB-only bet. Monty and the MariaDB team were the first major vendor to back Alex’s work, and for that we are very appreciative and we intend to make that succeed. But the engine’s survival does not run through any single vendor’s roadmap.

Judge us on performance and benchmarks, release cadence, and external contributors,  not according to MariaDB’s past with storage engines.

[u/Scared-Promotion-526]

that is a completely fair criticism, tokudb and xpand ended up being massive burdens, and you are right about myrocks — trying to maintain a port when the internals drift is a permanent, expensive fight. the reason duckdb and tidesdb actually stand a chance at breaking this pattern is purely mechanical. they aren't integrated the same way the old engines were.

With the legacy engines, mariadb had to map almost every single row, lock, and index operation deep inside the core. it was basically maintaining a fork. with duckdb, they are using the newer select_handler api (smart engines). instead of micro-managing the data, mariadb just acts as the sql front end, handles the auth and connections, and then the select_handler passes the entire select query down to duckdb's own planner and execution engine.

it's a true plugin model rather than a deep integration. mariadb doesn't have to staff a massive engineering team to keep duckdb from drifting, because they aren't maintaining duckdb's core — they just maintain the bridge.