Skip to main content
All comparisons/ScramDB vs PostgreSQL

ScramDB vs PostgreSQL

ScramDB is a PostgreSQL you never have to escape from. Your driver, your SQL, your serializable transactions, your row-level security, all unchanged. The engine underneath is columnar and compiles queries to native machine code, so the analytical half of your workload stops needing a second database.

Faster
377x
ScramDB 31.6s against PostgreSQL 11,896s. Both systems answered every query.
Faster from cold
66x
ScramDB 189s against PostgreSQL 12,391s. First touch, nothing cached.
Faster to load
1.3x
ScramDB 717s against PostgreSQL 937s. Full 100M row ingest.
Smaller on disk
6.2x
ScramDB 16.1 GiB against PostgreSQL 99.2 GiB. Same data, after load.
At a glance

Side by side

ScramDBPostgreSQL
StorageColumnar and compressed: 16 GiB for the 100 million row datasetRow heap plus WAL. No columnar storage in core
ExecutionQueries compile to native machine code and run on every core: a full analytical workload over 100 million rows in 31.6 secondsTuple-at-a-time executor with parallel query and LLVM JIT for expressions above a cost threshold
Analytics on live dataOne copy. The analytical query reads the same rows the transaction just wroteNo columnar path in core. The standard answer is CDC into a second, separate system
TransactionsFull ACID up to serializable isolation, and a transaction across machines that commits everywhere or nowhereFull ACID, all four isolation levels
Scale outTurn on clustering when you need it, with the same guarantees across the cluster and across regionsSingle node in core. Sharding needs an extension or a fork
Wire protocolPostgreSQL wire protocol, and the drivers you already use: psql, psycopg, asyncpg, SQLAlchemy, Django, JDBC, Npgsql, pgx, sqlx and node-postgresPostgreSQL, natively
AI and agentsA semantic layer built into the engine that AI agents connect to directly, bound by the same roles and row-level security as any userNone in core
BranchingFork the database instantly, or open it as it was at any past timestamppg_dump and restore, or filesystem snapshots

The same questions, 377 times faster

This is not a tuned configuration against an untuned one. ScramDB ran stock, GPU off, no per-benchmark flags, and PostgreSQL ran the community’s own published configuration on the same instance type. The gap is the engine: a row store read one row at a time against a compressed columnar store scanned by compiled code on every core.

Adding indexes to PostgreSQL closes part of the gap and opens another one. The indexed configuration is 129x slower than ScramDB instead of 377x, and it pays for that with 115.84 GiB on disk against ScramDB’s 16.07 GiB, and a load that takes 10,357 seconds against 717.

You keep the whole Postgres surface

Joins including LATERAL, window functions, recursive and writable CTEs, foreign keys, CHECK constraints, triggers of every flavour, PL/pgSQL procedures, prepared statements, COPY in CSV and binary, roles with GRANT and REVOKE, and row-level security policies with USING and WITH CHECK. Your ORM does not know the difference, because the wire protocol and the SQL are the ones it already speaks.

Isolation goes all the way up. Serializable here is genuinely serializable, so the concurrency anomalies you would otherwise design around cannot happen.

Where PostgreSQL still earns its place

Thirty-five years of extensions is not a thing you replace on a slide. PostGIS, the operator classes, the FDW ecosystem and the accumulated operational knowledge in your team are all real assets. If your workload is single-node OLTP with modest analytical needs and you are happy, stay happy.

The moment the analytical half starts pushing you toward a warehouse and a pipeline to feed it, that is the moment ScramDB is worth twenty minutes of your time.

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.