ScramDB vs SingleStore
SingleStore makes the same architectural argument we do: one engine for transactions and analytics. The differences are the licence and the guarantee. SingleStore is proprietary, its free self-managed edition is capped at 8 vCPU and 32 GB of RAM with community support only, and its documented isolation level is read committed. ScramDB is a binary you download, its free tier is bounded by stored data rather than by CPU, and it offers serializable isolation.
Side by side
| ScramDB | SingleStore | |
|---|---|---|
| Storage choice | One columnar store. Nothing to choose per table | Rowstore or columnstore per table. Universal Storage is the columnstore path |
| Isolation | Read committed, repeatable read and serializable isolation | READ COMMITTED, documented as the isolation level |
| Free tier | Community edition, free, up to 64 GiB of stored data, no CPU cap | Self-managed free edition capped at 8 vCPU and 32 GB RAM, community support only |
| Source | Single binary you download and run | Proprietary, commercial |
| Minimum deployment | One process | Aggregator plus leaf nodes |
| Wire protocol | PostgreSQL wire protocol | MySQL protocol, plus a MongoDB-compatible interface |
| AI and agents | A semantic layer built into the engine that AI agents connect to directly, bound by the caller’s own permissions | Native VECTOR type with several ANN index types on columnstore tables |
The closest peer on the board, and we lead it
SingleStore is the one system here that makes the same architectural argument we do, so this is the comparison worth taking seriously. On the published run for this machine it was slower on the queries, slower from cold and larger on disk, with five queries left unanswered, and that run is a tuned configuration. ScramDB ran stock, with no per-test flags and the GPU off.
The isolation difference matters
SingleStore documents read committed. ScramDB gives you serializable isolation, so the concurrency anomalies you would otherwise have to design around cannot happen. If you are moving money or enforcing an invariant that spans rows, that is not a footnote.
The closest peer on the board, and we lead it
SingleStore is the one system here that makes the same architectural argument we do, so the comparison is the one worth taking seriously. On the published run for this machine it was slower on the queries, slower from cold and larger on disk, with five queries left unanswered, and that run is a tuned configuration. ScramDB ran stock, with no per-test flags and the GPU off.
One process, and a licence you do not have to negotiate
ScramDB starts as a single binary with no aggregator and no leaf nodes to place, and grows into a cluster on the same binary when you need it. The free edition is bounded by how much data you store rather than by how many cores you may use, so a laptop and a 64 core server run the same engine at full speed.
When SingleStore is the right answer
You want a managed cloud service with a mature vector story and an enterprise support contract, and the licence and per-credit pricing are not obstacles. Its universal storage design is genuinely good engineering.
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