BenchDB is a self-hosted results system for continuous performance testing. Bring any benchmark harness, submit structured JSON, and get comparable histories, fleet-aware trends, and CI regression reports.
Learn how it works at benchdb.io or start with the quickstart.
A benchmark result is more than a timestamp and a number. To decide whether a change helped or hurt, you also need to know:
- what code and benchmark produced the measurement;
- which machine and environment ran it;
- which other results are genuinely comparable; and
- whether the change is meaningful relative to recent variation.
BenchDB stores that context with each result. It groups comparable results into histories, keeps machine-specific statistical trends distinct, and connects CI decisions to the underlying measurements. Raw observations, units, errors, runs, batches, commits, and machine metadata remain available when you need to investigate.
BenchDB does not run or schedule benchmarks. Your existing harness owns the workload; BenchDB accepts, organizes, compares, and presents its results.
Grafana time-series panels are excellent for querying and visualizing timestamped metrics from many data sources. That makes Grafana a natural home for service health and machine telemetry. It can also display benchmark measurements when you build the storage model, queries, dashboards, and comparison rules yourself; Grafana's k6 integration is one example of that approach.
BenchDB provides the benchmark-specific layer: structured results, commit and run identity, comparable-series rules, machine-aware histories, baseline selection, regression classification, and CI reports. Use Grafana when your main question is “what is this system doing over time?” Use BenchDB when it is “did this code change performance, and what evidence supports that answer?” The two tools can be used together.
BenchDB is designed for teams that:
- benchmark commits or releases repeatedly;
- compare results across a fleet without pretending different machines are interchangeable;
- need benchmark history and regression decisions in CI;
- want failed publication to be retryable without rerunning expensive work; or
- have benchmarks in multiple languages that can emit JSON.
It is probably unnecessary for a one-off local timing exercise. It is also not a general metrics, logs, or traces platform, and it will not schedule or execute your benchmark workloads.
- a Go server and CLI;
- a PostgreSQL result store;
- an API and generated Go client;
- a web dashboard for results, histories, fleet trends, and comparisons; and
- CI reporting with pairwise and recent-history regression analysis.
The Go module is go.kenn.io/benchdb. The server embeds the Svelte web app, so
the resulting bin/benchdb executable contains both the service and CLI.
make build
./bin/benchdb serve
./bin/benchdb results submit results.json --server https://example.comContributor setup, tests, documentation builds, and website deployment are in the contributing guide.
BenchDB is under active development. Its command and storage interfaces can change before the first stable release.
BenchDB began as an independent fork of the Go rewrite developed on
Conbench's experimental-v2 branch. We
are grateful to the Conbench contributors for that foundation and for the
project's original vision of language-independent continuous benchmarking.
BenchDB is now developed independently for a different product direction. See NOTICE.md and LICENSE for attribution and license terms.