ScramDB vs TimescaleDB
TimescaleDB is the best answer available inside PostgreSQL: hypertables, a columnstore for older chunks, and full Postgres transactions throughout. It is still the PostgreSQL executor underneath, with no vectorized engine or JIT of its own, and its multi-node story was deprecated in 2.13. ScramDB is 18x faster on the same queries and clusters natively when you need it.
Side by side
| ScramDB | TimescaleDB | |
|---|---|---|
| Storage | One columnar store for all data, at every age. Nothing to convert, no policy to tune | Hypercore: recent chunks in the Postgres row heap, older chunks converted to a compressed columnstore |
| Execution | Queries compile to native machine code and run on every core: 31.6 seconds for the whole analytical workload | PostgreSQL’s executor with parallel query. No separate vectorized or JIT engine beyond what Postgres provides |
| Updating old data | An ordinary transactional UPDATE at any age | UPDATE and DELETE work on compressed chunks; unfiltered ones can convert whole batches back to rowstore and recompress |
| Scale out | Turn on clustering when you need it, with the same guarantees across the cluster and across regions | Multi-node deprecated as of 2.13. Single node plus streaming replication |
| Beyond time series | A general-purpose relational database that happens to be fast at time ranges | Optimized around a time partitioning key |
| AI and agents | A semantic layer built into the engine that AI agents connect to directly, bound by the caller’s own permissions | pgvector and pgvectorscale, a strong vector story |
| Transactions | Full ACID up to serializable isolation, across one machine or many | Full PostgreSQL ACID, inherited |
| License | Community free to 64 GiB stored, Enterprise for clustering | Apache 2.0 core with advanced features under the Timescale License |
Where the 18x comes from
TimescaleDB’s columnstore is a genuine improvement on a heap, and it shows: 569 seconds against PostgreSQL’s 11,896. ScramDB answered the same queries in 31.56 seconds. The remaining gap is the executor. Compressed columns still have to be handed to the PostgreSQL executor, which was not built to run vectorized code over them, and there is no JIT that compiles the whole pipeline to native machine code.
One store, not two tiers
ScramDB has no rowstore-to-columnstore conversion policy to configure, no compression job to schedule and no chunk age to reason about. Data lands in the columnar store immediately and an UPDATE against a two-year-old row is an ordinary transactional statement.
When TimescaleDB is the right answer
You are on PostgreSQL, your workload is genuinely time series, and you want the win without leaving the ecosystem. That is a very good position and TimescaleDB serves it well, with continuous aggregates and retention policies that are hard to beat inside Postgres.
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