ScramDB vs Greenplum
Greenplum was the classic PostgreSQL MPP warehouse. In May 2024 its repositories were archived and the product became proprietary, and its engine still tracks PostgreSQL 12. It also remains a coordinator plus segment cluster to operate, fed from a transactional database somewhere else. ScramDB is one binary on a current engine, holding the transactions and answering the analytics on the same copy.
Side by side
| ScramDB | Greenplum | |
|---|---|---|
| Availability | Download the binary and run it | Proprietary since 2024; the open repositories are archived |
| Engine lineage | Its own engine, current | PostgreSQL 12 lineage |
| What you deploy | One binary, one process | A coordinator plus segment hosts, each running several instances, with mirrors |
| Transactional workload | Served by the same engine on the same copy | An analytical warehouse fed from elsewhere |
| 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 | Not part of the product |
| Wire protocol | PostgreSQL wire protocol, every standard driver and BI tool | PostgreSQL wire protocol |
| Row-level security | Policies enforced in the engine for every reader | PostgreSQL 12 era support |
A warehouse you can no longer read the source of
The repositories were archived in 2024 and current releases ship inside a commercial suite. If you are on Greenplum, your upgrade path is a vendor conversation, and the engine underneath is a PostgreSQL generation that stopped taking new features years ago.
One process instead of a cluster
Greenplum spreads work across a coordinator and many segment instances, which is how it scales and also what you operate. ScramDB is one static binary that uses every core of the machine it is on, and it is the transactional database as well, so there is no pipeline feeding it.
When Greenplum is the right answer
You already run it, the SQL estate is large, and a commercial support contract with the current owner is the least disruptive path forward.
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