ScramDB vs Amazon Redshift
Redshift’s own documentation says it plainly: primary key, foreign key and unique constraints are informational only and are not enforced. It is available only as an AWS service, billed per node hour or per processing unit, and it is built for analytical batch work rather than the transactional half of your application. ScramDB enforces its constraints, runs anywhere you can copy a binary, and answers a full analytical workload over 100 million rows in 31.6 seconds while serving transactions on the same data.
Side by side
| ScramDB | Amazon Redshift | |
|---|---|---|
| Deployment | One binary, your hardware or any cloud | AWS only: provisioned clusters or serverless workgroups |
| Keys and constraints | Primary keys, foreign keys, unique and CHECK constraints, enforced | Informational only, explicitly not enforced. NOT NULL is the exception |
| Transactional workload | Served by the same engine on the same copy | Analytical and batch oriented, fed by a pipeline from elsewhere |
| Cost model | The machine you already run | Node hours, or processing unit hours with a 60 second minimum, plus concurrency scaling |
| Isolation | Read committed, repeatable read and serializable | Snapshot and serializable |
| Wire protocol | PostgreSQL wire protocol, every standard driver | PostgreSQL derived, with its own dialect and limits |
| AI and agents | A semantic layer inside the engine that agents connect to directly, bound by the caller’s own permissions | Redshift ML calls out to SageMaker; native vector search unverified |
| Branching | Fork the database instantly, or open it as it was at any past timestamp | Snapshots and restores of a cluster |
Unenforced keys are a data quality problem waiting to happen
When the warehouse treats a foreign key as a hint, nothing stops an orphaned row from landing, and the planner may even make decisions on the assumption that it cannot. Every guarantee has to be re-implemented in the pipeline that feeds it. ScramDB enforces the constraint where the data lives, once.
A warehouse is only half a deployment
Redshift holds a copy of data that lives somewhere else, which means a pipeline, a schedule and a lag. ScramDB holds the data, serves the transactions against it, and answers the analytical questions from the same rows, so the reporting number and the application number are the same number.
When Redshift is the right answer
You are deep in AWS, your analytics is batch shaped, and the integration with S3, Glue and QuickSight is worth more to you than owning the 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