ScramDB vs Elasticsearch
Elasticsearch is a search engine, and using it as an analytical database means living with its model: no cross-document transactions, updates implemented as get-modify-reindex rather than in-place mutation, and joins that its own documentation calls prohibitively expensive in a distributed system. ScramDB answered the same analytical workload many times faster, with ordinary SQL joins, ordinary transactions and ordinary updates.
Side by side
| ScramDB | Elasticsearch | |
|---|---|---|
| Transactions | Full ACID up to serializable isolation across many rows | Optimistic concurrency on a single document. No cross-document transactions |
| Updating a row | An in-place transactional UPDATE | Get, modify and reindex the document |
| Joins | Every SQL join | Denormalisation, nested or parent-child queries, or a single-field lookup join |
| Query language | PostgreSQL SQL, on the PostgreSQL wire protocol | Query DSL, or its own SQL and pipeline languages |
| Referential integrity | Foreign keys, CHECK constraints, triggers, stored procedures | Not part of the model |
| Storage footprint | Columnar and compressed | Inverted indexes, which are larger than the source data |
| AI and agents | A semantic layer inside the engine that agents connect to directly, bound by the caller’s own permissions | Dense vector fields with approximate nearest neighbour search, a genuine strength |
| License | Community free up to 64 GiB stored, Enterprise beyond | Elastic License 2.0, SSPL or AGPLv3 |
Search-shaped storage costs you at analysis time
Inverted indexes are built to find documents, not to scan and aggregate columns. That shows up twice: in the time an aggregation over a hundred million rows takes, and in the disk it occupies to get there.
The relational parts are the parts that are missing
No cross-document transactions, no foreign keys, no triggers, no procedures, and joins that its documentation steers you away from. Teams work around all of it by denormalising, which means writing the same fact in several places and hoping every writer agrees. ScramDB gives you the relational guarantees and the analytical speed in one engine.
When Elasticsearch is the right answer
Full text search. Analyzed text, relevance scoring, fuzzy and phrase matching at scale, plus a mature vector search story. If search is the product, Elasticsearch is the right tool and ScramDB is not trying to replace it.
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