ScramDB vs CrateDB
CrateDB speaks the PostgreSQL wire protocol over Lucene storage, which makes it look like a relational database until you open a transaction. Its documentation is explicit that multi-statement transactions are not supported and that START TRANSACTION is accepted for compatibility and silently ignored, leaving optimistic row versions as the concurrency story. ScramDB gives you the protocol and the transactions, and answered the same analytical workload 9.8 times faster.
Side by side
| ScramDB | CrateDB | |
|---|---|---|
| Transactions | Full ACID up to serializable isolation | No multi-statement transactions. START TRANSACTION is accepted and ignored |
| Concurrency control | Real isolation levels, up to serializable | Optimistic concurrency through per-row version numbers |
| Storage | Columnar and compressed | Lucene: inverted indexes, doc values and BKD trees |
| Referential integrity | Foreign keys, CHECK constraints, triggers, procedures | Not part of the model |
| Deployment | One binary, one process | Three or more nodes recommended for production |
| Wire protocol | PostgreSQL wire protocol, every standard driver | PostgreSQL wire protocol, with documented gaps around transactions |
| Branching | Fork the database instantly, or open it as it was at any past timestamp | Snapshots |
| AI and agents | A semantic layer inside the engine that agents connect to directly, bound by the caller’s own permissions | Vector type with nearest neighbour search |
A protocol without the promises behind it
Speaking the PostgreSQL wire protocol means your driver connects. It does not mean BEGIN does anything. An ORM that wraps a unit of work in a transaction will run happily against CrateDB and give you none of the atomicity it was written to rely on.
ScramDB speaks the same protocol and keeps the promise: real transactions, real isolation levels up to serializable, and a distributed commit that finishes even if the client drops.
When CrateDB is the right answer
Large scale time series and search-flavoured analytics where documents are appended rather than updated in transactions, under a fully open Apache 2.0 licence.
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