ScramDB vs ClickHouse
ClickHouse is an analytics engine, and its own documentation is clear about the rest: multi-statement transactions are experimental and limited to non-replicated MergeTree, there are no foreign keys, no triggers and no stored procedures, and UPDATE and DELETE are asynchronous background mutations rather than transactional statements. So ClickHouse lives beside a real database, with a change-data-capture pipeline between them. ScramDB answers a full analytical workload over 100 million rows in 31.6 seconds and serves the transactional workload on the same copy of the data. One system, no pipeline, no lag.
Side by side
| ScramDB | ClickHouse | |
|---|---|---|
| Built for | Transactions, analytics and AI on one live copy | Online analytical processing on append-heavy data |
| Transactions | Full ACID up to serializable isolation, and a transaction across machines that commits everywhere or nowhere | ACID guaranteed for a single INSERT into a single partition. BEGIN and COMMIT are documented as experimental, limited to non-replicated MergeTree, and unsupported in ClickHouse Cloud |
| UPDATE and DELETE | Ordinary transactional statements, visible the moment they commit | Mutations: asynchronous background rewrites of data parts, not atomic row operations |
| Referential integrity | Foreign keys, CHECK constraints, triggers, stored procedures | No foreign keys, no triggers, no stored procedures. CHECK constraints are advisory |
| Point lookups | Indexed access on the same copy | The sparse index reads a full granule of 8,192 rows to return one. Documented as unsuitable for OLTP-style access |
| Wire protocol | PostgreSQL wire protocol, every standard driver and BI tool | A native protocol plus HTTP, with a separate driver per language |
| AI and agents | A semantic layer built into the engine that AI agents connect to directly, bound by the caller’s own permissions | A vector similarity index, which must be fully in memory to search |
| What you operate | One binary, one copy, one backup | ClickHouse, plus a transactional database, plus the pipeline between them |
The second system is the real cost
Nobody runs ClickHouse alone. It sits beside PostgreSQL or MySQL, which holds the truth, and a change-data-capture pipeline keeps it fed. That pipeline is a system: it has lag, it has failure modes, it has a bill, it has a pager, and it means the number on your dashboard is always a little behind the number in your application.
ScramDB removes the second system. Transactions and analytics run on the same live copy, so a dashboard reads the row a transaction wrote a millisecond ago. There is nothing to keep in sync because there is nothing to sync.
What the analytics engine gives up
ClickHouse has no foreign keys, no triggers and no stored procedures, so every invariant you would enforce in the database moves into application code. UPDATE and DELETE become mutations, applied asynchronously in the background rather than committed. And the sparse index that makes scans fast makes single-row lookups expensive by construction, because the smallest thing it can read is a granule of 8,192 rows.
ScramDB keeps all of it: joins, window functions, recursive CTEs, foreign keys, triggers, PL/pgSQL procedures, roles, row-level security, prepared statements, and serializable transactions, on a columnar engine that answers the analytical questions in seconds.
When ClickHouse is the right answer
Immutable event streams at petabyte scale, log and observability pipelines, and dashboards over data nobody updates. If that is genuinely your entire workload and you have no transactions to serve, ClickHouse is a strong choice.
Other head to heads
Same wire protocol, same drivers, same SQL. A columnar engine and native-code execution underneath.
No columnar storage, no vectorized execution, no parallel query in the community server. Every analytical scan is a row walk.
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