ScramDB vs Citus
Citus turns PostgreSQL into a distributed database by sharding tables across worker nodes. It is a clean design and it does not change what happens inside each shard: a row heap, read by the PostgreSQL executor, one tuple at a time. ScramDB answered the same analytical workload 55 times faster on a single node, and the queries that do not align with your distribution column still work.
Side by side
| ScramDB | Citus | |
|---|---|---|
| Storage | Columnar and compressed for every table | PostgreSQL row heap per shard, with an optional columnar table access method |
| Execution | Queries compile to native machine code and use every core | The PostgreSQL executor per shard, coordinated across workers |
| Distribution key | None to choose. Any query is a query | Co-location design decides which queries stay fast; unaligned joins repartition through the coordinator |
| What you deploy | One binary, one process | A coordinator plus worker nodes, each a PostgreSQL instance |
| Vacuum and bloat | Nothing to schedule, nothing to reclaim by hand | PostgreSQL autovacuum on every node |
| Wire protocol | PostgreSQL wire protocol, every standard driver | PostgreSQL, natively |
| 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 | Extensions, per node |
Sharding moves the problem, it does not solve it
Spreading a slow scan across eight machines makes it eight times less slow, at the cost of a cluster to run, a distribution column to design around, and a coordinator in the path of anything that does not co-locate. ScramDB makes the scan fast in the first place: columnar storage, block pruning and compiled execution, on one machine.
When Citus is the right answer
Multi-tenant SaaS with a natural tenant key, where the workload shards cleanly and staying inside the PostgreSQL extension ecosystem matters more than the per-node engine.
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