ScramDB vs MariaDB
MariaDB’s own project pages tell this story: ColumnStore’s server integration has long carried a beta label, and the DuckDB storage engine announced in 2026 is explicitly alpha and "not recommended for production at this time". Stock MariaDB on InnoDB took 147,906 seconds to answer the same questions. ScramDB answered them in 31.56 seconds, in production, today.
Side by side
| ScramDB | MariaDB | |
|---|---|---|
| Analytical engine | Columnar analytics in the shipping product, today | ColumnStore at beta server integration; the DuckDB engine is alpha and not recommended for production |
| Execution | Queries compile to native machine code and run on every core | No vectorized or JIT engine for InnoDB or Aria |
| Transactions | Full ACID up to serializable isolation, across one machine or many | InnoDB ACID, all four isolation levels, XA |
| Scale out | Turn on clustering when you need it, across machines and across regions | Galera synchronous multi-master. Xpand distributed SQL is a separate Enterprise product |
| Wire protocol | PostgreSQL wire protocol | MySQL protocol |
| AI and agents | A semantic layer built into the engine that AI agents connect to directly, bound by the caller’s own permissions | MariaDB Vector: native VECTOR type and HNSW index, GA in 11.8 |
| Row-level security | CREATE POLICY with USING and WITH CHECK, RESTRICTIVE and FORCE RLS | Not present; views and privileges are the workaround |
| License | Community free to 64 GiB stored, Enterprise for clustering | GPLv2 for the server; some tools under the BSL |
What the benchmark measured
The published run is stock MariaDB with InnoDB, and the result is 147,906 seconds against ScramDB’s 31.56. Forty-one hours against half a minute. It is the same structural story as MySQL: a row store, no parallel query, no vectorized execution.
The interesting number is the one MariaDB is chasing. The DuckDB storage engine plugin gets the analytics much closer, which is exactly why the project built it. It is also, in the project’s own words, alpha.
Vector search, honestly compared
MariaDB 11.8 ships a native VECTOR type with an HNSW index, and that is genuinely ahead of where ScramDB is: ScramDB stores embeddings in a text column with bundled cosine and dot-product functions, and a native vector type is on the roadmap rather than in the product. What ScramDB does bring to AI work is the semantic layer: an MCP server built into the engine, seventeen tools, structured filters that cannot be SQL-injected, and every call executed under the caller’s own roles and row-level security policies.
When MariaDB is the right answer
MySQL-compatible OLTP with Galera for synchronous multi-master availability, a GPL licence with no vendor gate, and now a GA vector type in the open source server.
Other head to heads
Same wire protocol, same drivers, same SQL. A columnar engine and native-code execution underneath.
ClickHouse cannot hold your transactions, so it lives next to a real database with a pipeline between them. ScramDB is both.
No columnar storage, no vectorized execution, no parallel query in the community server. Every analytical scan is a row walk.
Run it yourself in one line
One static binary, no dependencies. It picks its own config, listens on the postgres port 5432 and runs in the background.
$curl -fsSL https://scramdb.com/install | bash