ScramDB vs Databricks
Databricks is a lakehouse platform: Parquet files in object storage with a transaction log over them, billed in DBUs by the second and available only as a managed cloud service. Its documentation states that primary key, foreign key and unique constraints are informational and not enforced, and it is not built for row-level operational reads and writes. ScramDB enforces its constraints, serves the operational workload, and answers the analytical questions on the same copy of the data, on a binary you run yourself.
Side by side
| ScramDB | Databricks | |
|---|---|---|
| What it is | A database: transactions, analytics and AI on one live copy | A lakehouse platform over Parquet files in object storage |
| Deployment | One binary on your hardware or any cloud | Managed service on AWS, Azure or GCP |
| Constraints | Primary keys, foreign keys and unique constraints, enforced | Informational only, not enforced. NOT NULL and CHECK are enforced |
| Transactions | Full ACID up to serializable isolation across your schema | Write-serializable per table through the transaction log, with optimistic concurrency: conflicting writers fail and retry |
| Operational reads and writes | The same engine serves them | Not the intended workload |
| Cost model | The machine you already run | DBUs consumed per second, plus separate storage units |
| Freshness | The moment the transaction commits | Streaming ingestion at a trigger interval, commonly seconds |
| AI and agents | A semantic layer inside the engine that agents connect to directly, bound by the caller’s own permissions | Vector search as a separate index built from a table and queried over REST |
Files in a bucket, and the machinery to pretend they are a table
A lakehouse is Parquet files plus a log that makes writes look atomic. It is a genuinely good design for large batch analytics on data that arrives by pipeline. It is a poor fit for an application that needs to read a row, change it, and read it back, which is why Databricks positions that work elsewhere.
ScramDB is a database first. The columnar store that answers the analytical query is the same store the transaction wrote to, so the freshness question never arises and there is no second engine to license, size or schedule.
Constraints your data can rely on
When keys are informational, nothing stops a duplicate or an orphan from landing, and query results computed on the assumption that they cannot exist are quietly wrong. ScramDB enforces primary keys, foreign keys, unique and CHECK constraints in the engine, on the way in.
When Databricks is the right answer
Large-scale data engineering and machine learning over open formats, where Spark, notebooks and MLflow are already how your team works and the data is measured in petabytes.
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