Skip to main content
All comparisons/ScramDB vs CockroachDB

ScramDB vs CockroachDB

CockroachDB and ScramDB agree on the hard part: serializable isolation, the PostgreSQL wire protocol, and staying available when a machine dies. They disagree on storage. Cockroach keeps rows in an LSM key-value store and vectorizes on the way out; ScramDB stores columns and compiles the query to native code. On the same questions ScramDB is 347 times faster, in a quarter of the disk.

Faster
347x
ScramDB 31.6s against CockroachDB 10,966s. Both systems answered every query.
Faster from cold
62x
ScramDB 189s against CockroachDB 11,787s. First touch, nothing cached.
Faster to load
1.1x
ScramDB 717s against CockroachDB 813s. Full 100M row ingest.
Smaller on disk
3.9x
ScramDB 16.1 GiB against CockroachDB 63.3 GiB. Same data, after load.
At a glance

Side by side

ScramDBCockroachDB
StorageColumnar and compressed: 16 GiB for the same dataPebble, an LSM key-value store. Row oriented, no columnar replica
ExecutionQueries compile to native machine code and run on every core: 31.6 seconds for the whole analytical workloadVectorized execution over columnar batches built in memory from row data
IsolationSerializable isolation, with read committed and repeatable read availableSERIALIZABLE by default, READ COMMITTED available
Single nodeOne binary, production ready on a single machineProduction guidance is 3 nodes minimum for the default replication factor
Analytics on live dataSame copy, no second system, no staleness windowSame copy, but read through a row store
AI and agentsA semantic layer built into the engine that AI agents connect to directly, bound by the caller’s own permissionsNone built in
BranchingFork the database instantly, or open it as it was at any past timestampBackup and restore
LicenseCommunity free to 64 GiB stored, Enterprise for clusteringCockroach Community License since v24.3: production use needs a commercial license unless you are under the revenue threshold

Same guarantees, different floor

Serializable by default is the right call and Cockroach makes it. So does ScramDB, and a transaction that spans machines still commits everywhere or nowhere.

The difference shows up when a query has to read a lot of rows. Cockroach answered them in 10,966 seconds and stored the dataset in 63.28 GiB. ScramDB answered in 31.56 seconds and stored it in 16.07 GiB. Reading rows quickly helps. Not having to read them at all helps more.

You can start on one node

ScramDB runs as one binary on one machine, and it is the same binary you cluster later. There is no separate single-node edition to grow out of, and no three-node floor to reach before production.

When CockroachDB is the right answer

Multi-region OLTP where survivability and geographic data placement are the requirement and the analytical workload is genuinely light. Cockroach’s automatic rebalancing and region-aware topologies are mature and well documented.

The measurement, as of 5 September 2026. A full analytical workload over 100 million rows of real web analytics data, run on a 16 vCPU AWS instance. Ours is a single ScramDB node in its stock configuration, with the GPU off and nothing tuned for the test. Rival figures are those systems’ own published results for the same instance type. These are the numbers as of that date, not a permanent scoreboard: the engine is tuned continuously and it has got faster through every round of this work, so a later run should read better than this one.

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

Quick start · How the engine works · Talk to us

A full analytical workload over 100 million rows of real web analytics data, run on a 16 vCPU AWS instance, measured 5 September 2026. Ours is a single ScramDB node in its stock configuration, with the GPU off and nothing tuned for the test. Rival figures are those systems’ own published results for the same instance type. These are the numbers as of that date, not a permanent scoreboard: the engine is tuned continuously and it has got faster through every round of this work, so a later run should read better than this one.