ScramDB vs MySQL
MySQL is a fine transactional database and a poor analytical one, by design. The community server has no columnar storage engine, no vectorized execution and no intra-query parallelism, so a 100 million row aggregation is a row-by-row walk on one core. ScramDB answers the same questions 696x faster, in 5.5x less disk, over a PostgreSQL wire protocol your driver already speaks.
Side by side
| ScramDB | MySQL | |
|---|---|---|
| Storage | Columnar and compressed: 16 GiB for the same data | InnoDB row store with optional page compression |
| Execution | Queries compile to native machine code and run on every core: 31.6 seconds for the whole analytical workload | No vectorized engine, no parallel query, no JIT in the community server. Hash join since 8.0.18 |
| Analytics on live data | Same copy, no export | Column-level analytics is a separate product (HeatWave), not the open source server |
| Transactions | Full ACID up to serializable isolation, and a transaction across machines that commits everywhere or nowhere | Full ACID on InnoDB, all four isolation levels |
| Scale out | Turn on clustering when you need it, with the same guarantees across the cluster and across regions | Replication and Group Replication for availability. No native sharding |
| 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 | VECTOR type with distance functions since 9.0; no mature ANN index in the base reference |
| License | Community free to 64 GiB of stored data, Enterprise for clustering and beyond | GPLv2 or a commercial license from Oracle |
The gap is structural, not a tuning problem
MySQL took 21,962 seconds to answer the queries ScramDB answered in 31.56. That is six hours against half a minute. No amount of tuning closes a gap of that shape, because the shape is architectural: InnoDB stores rows, reads them one at a time, and runs the query on a single core.
The load tells the same story from the other side. ScramDB ingested the 100 million rows in 717 seconds and kept them in 16.07 GiB. MySQL took 10,004 seconds and 87.95 GiB.
What you would be moving to
ScramDB speaks the PostgreSQL wire protocol rather than the MySQL one, so this is a migration, not a drop-in. What you get on the other side is the full relational surface you already rely on (foreign keys, triggers, stored procedures, prepared statements, roles and privileges) plus row-level security, serializable snapshot isolation, instant database branching and a built-in semantic layer for AI agents.
When MySQL is the right answer
High-throughput single-row OLTP with a mature replication story and the largest hosting ecosystem in the industry. If your queries are point reads and single-row writes and you never scan, MySQL is not the bottleneck and there is nothing here to fix.
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.
Documents are read whole, there is no columnar scan engine, and a transaction comes with a documented time limit and a document count guideline.
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