ScramDB vs MongoDB
MongoDB stores every document with its keys, reads it whole, and has no documented columnar or vectorized scan engine to aggregate a hundred million of them with. Its transactions carry a documented 60 second default limit, a 16 MB oplog entry cap and guidance to modify no more than a thousand documents. ScramDB gives you SQL with real joins, foreign keys and serializable transactions with none of those ceilings, on a columnar engine built for exactly the aggregation MongoDB was not.
Side by side
| ScramDB | MongoDB | |
|---|---|---|
| Data model | Relational with full SQL, plus JSONB when you want documents | BSON documents, queried through the aggregation pipeline |
| Storage | Columnar and compressed: 16 GiB for the same data | WiredTiger document store, snappy block compression |
| Execution | Queries compile to native machine code and run on every core: 31.6 seconds for the whole analytical workload | Aggregation pipeline. No documented columnar or vectorized scan engine |
| Transactions | Full ACID up to serializable isolation, with no document count or duration ceiling on a transaction | Multi-document ACID on replica sets and sharded clusters, with a documented 60 second default limit, a 16 MB oplog entry cap and guidance of 1,000 documents or fewer per transaction |
| Joins | Every SQL join, including LATERAL, on indexed columns | $lookup in the pipeline |
| Wire protocol | PostgreSQL wire protocol, every standard driver and BI tool | MongoDB drivers |
| AI and agents | A semantic layer built into the engine that AI agents connect to directly, bound by the caller’s own permissions | Atlas Vector Search, documented as a managed-cloud capability |
| License | Community free to 64 GiB stored, Enterprise beyond | SSPL v1, which is neither OSI nor FSF approved |
A document store reads documents
Aggregating a hundred million records in MongoDB means reading a hundred million whole documents, keys included, through a pipeline with no columnar or vectorized scan engine underneath it. That is not a criticism of MongoDB’s engineering, it is what the storage model implies.
ScramDB reads only the columns a query touches, skips whole blocks that cannot match, and compiles the query to native machine code. The same question costs a fraction of the work.
Flexible schema without giving up SQL
If the reason you are on MongoDB is that the shape of your data changes, ScramDB has JSONB with the operators and indexes to go with it, inside a relational database with foreign keys, constraints and serializable transactions. You get the flexible column where you need one and a real schema everywhere else, plus joins that are joins.
When MongoDB is the right answer
Deeply nested documents that are read and written whole, horizontal write scaling through native sharding, and teams who want to move fast without a schema conversation. MongoDB is good at that and its sharding story is mature.
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