ScramDB vs OceanBase
OceanBase is a serious distributed database with an LSM engine, Paxos replication and MySQL or Oracle compatibility modes. It also requires at least three servers for production, fixes each tenant’s compatibility mode at creation time, and keeps its enterprise features commercial. ScramDB answered the same analytical workload 75 times faster from a single process, and clusters on the same binary when you want it to.
Side by side
| ScramDB | OceanBase | |
|---|---|---|
| Minimum production deployment | One process | At least three servers; a single node is for learning and development |
| Storage | One columnar store | LSM tree with an in-memory write buffer, plus a columnar engine for analytics |
| Wire protocol | PostgreSQL wire protocol, every standard driver | MySQL protocol, or an Oracle compatible mode, fixed per tenant at creation |
| Analytics on live data | Same copy, same engine | One engine, with compaction between the write buffer and the baseline data |
| 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 | Vector type with several index types |
| Editions | Community free up to 64 GiB stored, Enterprise for clustering | Community edition Apache 2.0; enterprise and cloud are commercial |
| Getting started | One command, one binary | A cluster, its tenants and their compatibility modes |
Three servers is a decision, not a default
A production floor of three machines means the smallest useful deployment is a cluster, with the operational surface that implies. ScramDB runs in production on one process and joins the cluster when you turn clustering on, using the same binary and the same configuration file.
When OceanBase is the right answer
Very large distributed OLTP with strong consistency requirements, particularly where MySQL or Oracle compatibility and multi-tenancy are hard requirements.
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