Benchmarks

Does Timelake beat what a team would otherwise build for time series on object storage? We stream the same IoT data into Timelake, naive Iceberg (the S3 Tables write pattern) and Lance, then run the same queries against each.

Workload

TSBS IoT: readings and diagnostics, 11.7M rows each over 3 days, 4,234 trucks, plus a tags table.

Ingest: 864 five-minute windows × 2 tables = 1,728 commits of about 13.5k rows (Firehose's default buffer interval). Every system gets identical rows.

Queries and states

The 12 TSBS IoT queries plus 5 single-truck queries. Each runs in a fresh process: one first run, then repeats.

Measured right after ingest (what readers see until a compaction job runs) and after each system's standard maintenance. All row counts matched across engines.

Environment

One M1 Pro laptop (10 cores). “S3” is RustFS behind a proxy that adds 20 ms before each response, roughly S3 in-region; it is not AWS.

Naive Iceberg is PyIceberg appends read by DuckDB; its maintenance simulates S3 Tables' default binpack compaction. Lance is read by DuckDB and by DataFusion with Lance's scanner.

Query time

Timelake's reader in blue; the multiplier is relative to the fastest engine.

S3 · right after ingest

First run, geometric mean over 12 queries. Lower is better.

S3 · after maintenance

First run, geometric mean over 12 queries. Lower is better.

Local disk · right after ingest

First run, geometric mean over 12 queries. Lower is better.

Local disk · after maintenance

First run, geometric mean over 12 queries. Lower is better.

Ingest

1,728 commits, 23.3M rows. Timelake's times include its inline compaction and snapshot expiry.

Storage	System	Wall time	Commit p50	Commit p95	Objects written
S3 (RustFS +20 ms)	timelake	433.8 s	163 ms	620 ms	1,082
S3 (RustFS +20 ms)	lance	816.9 s	425 ms	863 ms	5,187
S3 (RustFS +20 ms)	iceberg	1606.9 s	922 ms	1132 ms	6,921
local disk	lance	6.4 s	3 ms	6 ms	5,190
local disk	timelake	25.3 s	8 ms	43 ms	1,082
local disk	iceberg	306.3 s	173 ms	338 ms	6,921

TimescaleDB on Tiger Cloud

The same data and queries in a disposable Tiger Cloud service (us-east-1, DEV, shared CPU and memory: the smallest tier), as a plain hypertable and after converting every chunk to the columnstore. Client times are measured from a laptop and include the network round trip; server time subtracts the median round trip of SELECT 1. Timelake rows are its reader on this page's other setups, for reference: different hardware, so read ratios as indicative. Full write-up in bench/results/TIMESCALE.md.

Tiered storage (chunks on S3) is not measured yet: it has to be enabled in the Tiger Console, and it never became active on this service.

TSBS IoT (12 queries)

Geometric means over the 10 queries completed by every variant with data.

Variant	Completed	First run	First run (server)	Best repeat (server)
Hypertable (row store)	10/12	9.04 s	8.85 s	5.18 s
Hypertable, columnstore (compressed)	12/12	2.21 s	2.02 s	2.06 s
Timelake reader · RustFS +20 msreference	12/12	0.33 s	—	—
Timelake reader · local diskreference	12/12	66 ms	—	—

Single truck (5 queries)

Geometric means over the 5 queries completed by every variant with data.

Variant	Completed	First run	First run (server)	Best repeat (server)
Hypertable (row store)	5/5	0.26 s	72 ms	13 ms
Hypertable, columnstore (compressed)	5/5	68 ms	27 ms	4 ms
Timelake reader · RustFS +20 msreference	5/5	0.15 s	—	—
Timelake reader · local diskreference	5/5	9 ms	—	—

Caveats

One dataset and one machine. Real S3 adds bandwidth limits and latency variance that the proxy does not.
S3 Tables' managed compaction runs asynchronously and can sort if a sort order is configured; here it is binpack only, with all snapshots kept.
Lance compaction on RustFS needed upload concurrency 1 (concurrent multipart uploads failed), so Lance's S3 maintenance time is not comparable.
Timelake keeps replaced files for 1 hour (snapshot retention), so storage on disk exceeds the live table size until then.
Timelake's reader reuses a table version loaded in the last second for planning; its own commits are always visible.