bench(report): publish v0.6 strengths, limitations and tested size envelope

Closed
  • Is something wrong?
#329 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
28/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
data-engineering, performance

Research direction

Start with #328 and its olf bench results, then read ADR 0001, ADR 0007, and issues #53, #173, #323, and #110. Run the benchmark matrix for the specified sizes and scale, including the large public database ingestion; publish reproducible per size envelopes and bottlenecks in the docs. Done means size values are calibrated and ADR 0001 records the decision with evidence against each stated criterion.

Written by the indexing model from the issue text.

Description

priority: P0 roadmap track: workloads

Milestone: v0.6-alpha — Workloads, Sizing and Scale
Roadmap sequence: #183 (revised 2026-10-05)

Context

v0.6-alpha exit gate (demo scene 2). The target range is 100 GB–5 TB. Spark is likely overkill for that range and a second engine to operate; DuckDB is single-node and its Iceberg catalog writes and lineage are not yet mature enough to be the platform engine. Trino is kept, but the choice has to be confirmed with measurements, not assumed.

Scope

  • Run #328 for small/medium/large at SF1 through SF1000 (~1 TB; on a cloud cluster if the reference hardware cannot hold it) and the large public-database ingestion of #110.
  • Publish the envelope per size and the first bottleneck per component (dlt, Floe, Trino, storage) in the docs; calibrate the size values in #323; feed #49.
  • Trino decision criteria, recorded in ADR 0001:
    • TPC-DS SF1000 Gold build completes on large within an agreed time target;
    • Iceberg maintenance (compaction, snapshot expiry, orphan cleanup) runs through Trino (#53, #173);
    • OpenLineage emission from the pinned Trino version satisfies ADR 0007.
  • If a criterion fails, reopen ADR 0001 with the alternatives assessed. DuckDB remains the candidate for developer workspaces (#117), not the shared engine.

Acceptance criteria

  • The report is reproducible from olf bench results.
  • Size values are calibrated from it.
  • ADR 0001 records the decision and its evidence.
Dominant language
Python
Stars
26
Forks
6
Avg merge
7h 22m
Merged PRs (30d)
337

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from OpenLakeForge/openlakeforge

All issues in OpenLakeForge/openlakeforge

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.