ScramDB vs Trino
Trino is a federation engine: a coordinator and a fleet of workers that read other systems’ files and tables through connectors. It stores nothing, so every guarantee about your data belongs to whatever sits underneath, and multi-statement transactions are connector-dependent at best. ScramDB owns the storage, holds the transactions, and answered the same analytical workload 11 times faster.
Side by side
| ScramDB | Trino | |
|---|---|---|
| Owns the data | Yes: its own storage, with real transactions behind it | No: it reads other systems through connectors |
| Transactions | Full ACID up to serializable isolation across your schema | Transaction syntax exists; real guarantees depend on the connector underneath |
| What you deploy | One binary, one process | A coordinator plus worker nodes |
| Triggers and procedures | Triggers and PL/pgSQL procedures | No CREATE TRIGGER; procedures come from connectors |
| Row-level security | Policies enforced in the engine for every reader | Depends on the underlying system and catalog configuration |
| Wire protocol | PostgreSQL wire protocol, every standard driver | Its own client and JDBC driver |
| Branching | Fork the database instantly, or open it as it was at any past timestamp | Not applicable: it holds no data |
| 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 engine |
Federation is a feature, not a foundation
Querying across a lake, a warehouse and three databases from one SQL prompt is genuinely useful, and Trino is very good at it. It is also, structurally, a layer with nothing of its own: no storage, no durable transactions, no constraints, and a performance ceiling set by whatever it is reading from.
ScramDB is the thing underneath. It holds the rows, enforces the constraints and answers the analytical query from its own columnar store, on one machine, without a coordinator to size or workers to schedule.
When Trino is the right answer
You have data in five places, you are not consolidating it any time soon, and one SQL interface across all of it is worth a cluster. Trino is Apache 2.0 and does that job well.
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