ScramDB vs BigQuery
BigQuery is serverless analytics with a meter attached to every query: on-demand pricing is charged per tebibyte scanned, primary and foreign keys must be declared NOT ENFORCED and exist only as planner hints, and a mutating transaction is capped at 100 tables and blocks other mutating transactions on the same table. ScramDB runs on your own hardware with no per-query bill, enforces its constraints, and serves the transactional workload on the same copy the analytics reads.
Side by side
| ScramDB | BigQuery | |
|---|---|---|
| Deployment | One binary on your hardware or any cloud | Google Cloud service only, fully serverless |
| Cost model | The machine you already run | Per tebibyte scanned on demand, or per slot hour on capacity pricing, plus storage |
| Constraints | Primary keys, foreign keys, unique and CHECK constraints, enforced | Primary and foreign keys must be NOT ENFORCED. Integrity is the application’s problem |
| Transaction limits | No table or partition cap on a transaction | At most 100 tables mutated and 100,000 partition modifications per transaction |
| Concurrent writes | Writers do not queue behind each other | A mutating transaction blocks other mutating transactions on the same table |
| Isolation | Read committed, repeatable read and serializable | Snapshot isolation |
| Wire protocol | PostgreSQL wire protocol, every standard driver and BI tool | Its own API and SQL dialect |
| AI and agents | A semantic layer inside the engine that agents connect to directly, bound by the caller’s own permissions | Native vector search functions and vector indexes |
A meter on every question
Bytes-scanned pricing makes curiosity expensive. Teams start reviewing queries before running them, partitioning defensively, and building caches whose only purpose is to avoid the bill. ScramDB costs the same whether you ask one question or ten thousand, because the cost is the machine, not the query.
Integrity is not optional
BigQuery will let you declare a primary key, as long as you also declare that it is not enforced. Duplicates and orphans land, and the optimizer may make decisions assuming they cannot exist. ScramDB enforces keys and constraints in the engine, so the data is correct at rest rather than correct by convention.
When BigQuery is the right answer
Bursty, unpredictable analytical workloads inside Google Cloud where you never want to think about capacity, and the data arrives from pipelines you already run there.
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