ScramDB vs Firebolt
Firebolt is built for one half of the job. Its primary index is explicitly not a uniqueness constraint, primary and foreign keys are not enforced, nothing in its documentation positions it for transactional work, and concurrency is bought by starting more engines, each billed by the second. ScramDB is a single binary you run wherever you like: it serves the transactions and answers a full analytical workload over 100 million rows in 31.6 seconds, on the same copy of the data, with no compute meter running.
Side by side
| ScramDB | Firebolt | |
|---|---|---|
| What it is | A database: transactions, analytics and AI on one live copy | An analytical engine, managed or self-managed on Kubernetes |
| Transactional workload | Serving it is the point | Not positioned for it. No OLTP story in the documentation |
| Keys and constraints | Primary keys, foreign keys and CHECK constraints, enforced | The primary index is a sparse index, documented as not a uniqueness constraint |
| Cost model | A binary you run. No compute meter, no per-engine billing | Firebolt Units billed per second, per engine, plus separate storage |
| Concurrency | One engine, all your cores | Start more engines and pay for each one |
| Self hosting | One static binary, one command | Self-managed edition via Helm chart or Kubernetes operator |
| Wire protocol | PostgreSQL wire protocol, every standard driver and BI tool | Its own SQL surface and drivers |
| AI and agents | A semantic layer built into the engine that AI agents connect to directly, bound by the caller’s own permissions | Vector search through a table function over array columns |
The meter is the difference
A rented engine bills by the second it is running, and buying concurrency means running more of them. That is a fine model when analytics is a scheduled batch. It is an awkward one when the analytics is your product and every customer session opens queries.
ScramDB is a binary. It runs on the machine you already pay for, uses every core of it, and costs the same whether one person is querying or a thousand.
A database, not a half of one
Firebolt does not claim to serve your transactions, so a Firebolt deployment implies a transactional database somewhere else and a pipeline to move data into it. ScramDB holds the transactions and answers the analytical questions from the same rows, with foreign keys, triggers, stored procedures, roles and row-level security intact.
When Firebolt is the right answer
Customer-facing analytics at very large scale, where the data arrives by pipeline, the queries are known, and aggressive indexing plus elastic compute is exactly the shape of the problem.
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