ScramDB vs StarRocks
StarRocks is a capable MPP analytics engine, and it is a cluster: frontend nodes for metadata and planning, backend nodes for storage and execution, three frontends for high availability. ScramDB answered the same analytical workload faster from a single process, while also serving the transactional half of the application that StarRocks expects to live somewhere else.
Side by side
| ScramDB | StarRocks | |
|---|---|---|
| What you deploy | One binary, one process | Frontend and backend nodes, three frontends for high availability |
| Transactional workload | Served by the same engine on the same copy | Load jobs are transactional; the operational database lives elsewhere |
| Wire protocol | PostgreSQL wire protocol | MySQL protocol |
| Referential integrity | Foreign keys, CHECK constraints, triggers, stored procedures | Not documented |
| Row-level security | Policies enforced in the engine for every reader | Not documented |
| Branching | Fork the database instantly, or open it as it was at any past timestamp | Backup and restore |
| AI and agents | A semantic layer inside the engine that agents connect to directly, bound by the caller’s own permissions | Vector index for approximate nearest neighbour search |
| License | Community free up to 64 GiB stored, Enterprise beyond | Apache 2.0 |
One process against a cluster
StarRocks splits metadata and execution across separate node types, which is how it scales past one machine and also what you have to operate before the first query runs. ScramDB is a single binary: it uses every core of the machine it is on, and it answered this workload faster than the cluster did.
And it holds your data, not a copy of it
StarRocks is fed from an operational database somewhere else. ScramDB is that database as well, so there is no pipeline, no lag and no second schema to keep aligned.
When StarRocks is the right answer
Very large real-time analytics that genuinely needs to scale across many machines, with a team that wants an Apache-2.0 MPP engine and is comfortable running a cluster.
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