ScramDB vs TiDB
TiDB’s HTAP works by keeping your data twice: rows in TiKV for transactions, a columnar replica in TiFlash for analytics, kept in step by asynchronous Raft Learner replication. It is a real architecture and it is two copies, two engines and a lag to reason about. ScramDB is one columnar copy that serves both, on one node if you want, and it answered the same queries 112x faster than the TiFlash side did.
Side by side
| ScramDB | TiDB | |
|---|---|---|
| Copies of your data | One. The analytical query reads the row the transaction just wrote | Two. TiKV rows plus a TiFlash columnar replica per table you opt in |
| Consistency for analytics | The same live data every other reader sees | Columnar replicas are asynchronously replicated as Raft Learners; consistency is reached by validating the Raft index at read time |
| Setup | One static binary. Clustering is opt-in configuration, not extra processes | PD, TiKV, TiDB and TiFlash processes, 3 or more of the first two |
| Isolation | Serializable isolation, with read committed and repeatable read available | Snapshot isolation, labelled Repeatable Read. Percolator two-phase commit through a timestamp oracle |
| Wire protocol | PostgreSQL wire protocol | MySQL protocol. Stored procedures, triggers and events are documented as unsupported |
| Procedures and triggers | PL/pgSQL procedures, row, statement, INSTEAD OF and event triggers | Not supported |
| AI and agents | A semantic layer built into the engine that AI agents connect to directly, bound by the caller’s own permissions | None built in |
| License | Community free to 64 GiB stored, Enterprise for clustering | Apache 2.0 for the core |
The second copy is the product
TiFlash exists because TiKV cannot answer analytical queries at speed, which is an honest engineering answer to a real problem. The cost is that every table you want to query analytically must be explicitly given a TiFlash replica, that replica lands asynchronously, and your operational footprint now includes a fourth component.
The columnar side of TiDB answered in 3,533 seconds, and left two queries unanswered. ScramDB answered all of them in 31.56 seconds, from the only copy it keeps.
One engine, one copy, one snapshot
ScramDB is UTAP rather than HTAP, and the distinction is exactly this: there is no second copy to keep in sync. The columnar store is the transactional store. A dashboard reading a metric sees the write that committed a millisecond ago because it is reading the same rows, not a replica of them.
When TiDB is the right answer
MySQL-protocol applications that need horizontal write scaling first and analytics second, with a team that is comfortable operating a multi-component distributed system. TiDB is Apache-2.0, mature and widely deployed at scale.
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