Add elosdb (c8g.4xlarge, c8g.metal-48xl, c6a.4xlarge)

[decster]

Add elosdb

elosdb is a single-node analytical database: a C++ storage and execution engine with its own column format, behind a server that speaks the PostgreSQL v3 wire protocol. It is a personal research project, not a production system.

How it runs

• install compiles nothing. It downloads one statically-linked executable for the box's architecture and checks it against the sha256 pinned in the script for that architecture. It refuses to continue on a mismatch, or on an architecture with no pinned asset:

  • aarch64: v0.1.10, built for Neoverse V2 (SVE2), sha256 44d2a66d…;
  • x86_64: v0.1.10, built -march=x86-64-v3 (AVX2/FMA/BMI2, no AVX-512), sha256 ce12bbf7….

  It also apt-installs postgresql-client for psql.

• start passes only --port and --data-dir; everything else is the binary's default (tuned: no).

• load runs create.sql and then one COPY hits FROM 'hits.parquet'. The store is built inside the timed load window.

• create.sql is umbra's column list with no per-column encoding hints. queries.sql is umbra's, unchanged.

• There is no result cache, and nothing is precomputed per query.

Results (ClickBench's own benchmark.sh driver, through the pinned install)

machine	binary (sha256)	date	load	data size	cold sum	hot sum	QPS
c8g.4xlarge	v0.1.10 aarch64 44d2a66d	2026-10-02	44.94 s	7.67 GB	29.66 s	2.00 s	12.05
c6a.4xlarge	v0.1.10 x86_64 ce12bbf7	2026-10-02	90.22 s	7.67 GB	34.66 s	5.34 s	4.95

These are my own runs of the pinned binaries. The result files in the PR are the CI's runs, which used the pins in place at the time. Each binary needs glibc >= 2.38.

validate-results.py --base <origin/main checkout> passes locally. All tags are existing ones.

🤖 Generated with Claude Code

[github-actions]

The run of elosdb on c6a.4xlarge did not produce results.

Logs:

• elosdb on c6a.4xlarge: benchmark log, cloud-init log

[decster]

Thanks for launching the run! elosdb ships an aarch64-only binary (the install script exits on x86_64, as in the log above), and the submitted results are for c8g.4xlarge and c8g.metal-48xl. Could you relabel this PR with machine:c8g.4xlarge (and machine:c8g.metal-48xl if possible) instead of machine:c6a.4xlarge?

[decster]

c6a.4xlarge

I've updated the PR to add c6a.4xlarge(build a new x86_64 binary) support

[github-actions]

Results for elosdb are ready for: c6a.2xlarge, c6a.4xlarge, c6a.metal, c7a.metal-48xl, c8g.4xlarge, c8g.metal-48xl.
The result files are committed as 813568d.
Removed manually added result files: elosdb/results/20260930/c8g.4xlarge.json, elosdb/results/20260930/c8g.metal-48xl.json.

Logs:

• elosdb on c8g.metal-48xl: benchmark log, cloud-init log
• elosdb on c7a.metal-48xl: benchmark log, cloud-init log
• elosdb on c8g.4xlarge: benchmark log, cloud-init log
• elosdb on c6a.metal: benchmark log, cloud-init log
• elosdb on c6a.4xlarge: benchmark log, cloud-init log
• elosdb on c6a.2xlarge: benchmark log, cloud-init log

[github-actions]

Results for elosdb are ready for: c6a.xlarge.
The result files are committed as 4544f05.

Logs:

• elosdb on c6a.xlarge: benchmark log, cloud-init log

[decster]

Thanks for running it on all those machines! I've pushed one more change (0fa8029): install now pins elosdb v0.1.9 on both architectures, sha256 0f69fac7… for aarch64 and 1ec9f68b… for x86_64. Nothing else in the submission changed. v0.1.9 mostly improves hot runs (c8g.metal-48xl 1.00 s → 0.89 s, c6a.4xlarge 6.35 s → 6.19 s in my runs). The result files committed by CI were measured with the previous pins (v0.1.7 / v0.1.8). Could you re-run when convenient so they match the pinned binaries? Sorry for the extra round.

[github-actions]

Results for elosdb are ready for: c6a.large.
The result files are committed as a105fc1.

Logs:

• elosdb on c6a.large: benchmark log, cloud-init log

[decster]

Thanks for the c6a.large run! I've pushed one more commit on top of the CI's (e343849): install now pins elosdb v0.1.10 on both architectures, sha256 44d2a66d… (aarch64) and ce12bbf7… (x86_64), and the README quotes the new runs. Nothing else in the submission changed. v0.1.9 stays published, so the earlier pins still resolve.

v0.1.10 mainly improves a few query shapes outside the 43 (quantiles, rank windows, string-prefix GROUP BY keys). I re-ran c8g.4xlarge and c6a.4xlarge through the pinned install; both pass all 43 queries.

The result files committed so far were measured with earlier binaries. Could you re-run when convenient so they match the pinned ones? Sorry again for the extra round.

[github-actions]

The run of elosdb on t3a.small did not produce results.

Logs:

• elosdb on t3a.small: benchmark log, cloud-init log